2018-05-02 19:01:23 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
|
|
|
/* XDP sockets
|
|
|
|
*
|
|
|
|
* AF_XDP sockets allows a channel between XDP programs and userspace
|
|
|
|
* applications.
|
|
|
|
* Copyright(c) 2018 Intel Corporation.
|
|
|
|
*
|
|
|
|
* Author(s): Björn Töpel <bjorn.topel@intel.com>
|
|
|
|
* Magnus Karlsson <magnus.karlsson@intel.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define pr_fmt(fmt) "AF_XDP: %s: " fmt, __func__
|
|
|
|
|
|
|
|
#include <linux/if_xdp.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/sched/mm.h>
|
|
|
|
#include <linux/sched/signal.h>
|
|
|
|
#include <linux/sched/task.h>
|
|
|
|
#include <linux/socket.h>
|
|
|
|
#include <linux/file.h>
|
|
|
|
#include <linux/uaccess.h>
|
|
|
|
#include <linux/net.h>
|
|
|
|
#include <linux/netdevice.h>
|
2018-06-04 20:05:57 +08:00
|
|
|
#include <linux/rculist.h>
|
2020-05-21 03:20:51 +08:00
|
|
|
#include <net/xdp_sock_drv.h>
|
2020-12-01 02:52:00 +08:00
|
|
|
#include <net/busy_poll.h>
|
2018-05-02 19:01:25 +08:00
|
|
|
#include <net/xdp.h>
|
2018-05-02 19:01:23 +08:00
|
|
|
|
2018-05-02 19:01:24 +08:00
|
|
|
#include "xsk_queue.h"
|
2018-05-02 19:01:23 +08:00
|
|
|
#include "xdp_umem.h"
|
2019-01-25 02:59:39 +08:00
|
|
|
#include "xsk.h"
|
2018-05-02 19:01:23 +08:00
|
|
|
|
2021-04-14 13:39:12 +08:00
|
|
|
#define TX_BATCH_SIZE 32
|
2018-05-02 19:01:34 +08:00
|
|
|
|
2019-12-19 14:10:02 +08:00
|
|
|
static DEFINE_PER_CPU(struct list_head, xskmap_flush_list);
|
|
|
|
|
2020-08-28 16:26:16 +08:00
|
|
|
void xsk_set_rx_need_wakeup(struct xsk_buff_pool *pool)
|
xsk: add support for need_wakeup flag in AF_XDP rings
This commit adds support for a new flag called need_wakeup in the
AF_XDP Tx and fill rings. When this flag is set, it means that the
application has to explicitly wake up the kernel Rx (for the bit in
the fill ring) or kernel Tx (for bit in the Tx ring) processing by
issuing a syscall. Poll() can wake up both depending on the flags
submitted and sendto() will wake up tx processing only.
The main reason for introducing this new flag is to be able to
efficiently support the case when application and driver is executing
on the same core. Previously, the driver was just busy-spinning on the
fill ring if it ran out of buffers in the HW and there were none on
the fill ring. This approach works when the application is running on
another core as it can replenish the fill ring while the driver is
busy-spinning. Though, this is a lousy approach if both of them are
running on the same core as the probability of the fill ring getting
more entries when the driver is busy-spinning is zero. With this new
feature the driver now sets the need_wakeup flag and returns to the
application. The application can then replenish the fill queue and
then explicitly wake up the Rx processing in the kernel using the
syscall poll(). For Tx, the flag is only set to one if the driver has
no outstanding Tx completion interrupts. If it has some, the flag is
zero as it will be woken up by a completion interrupt anyway.
As a nice side effect, this new flag also improves the performance of
the case where application and driver are running on two different
cores as it reduces the number of syscalls to the kernel. The kernel
tells user space if it needs to be woken up by a syscall, and this
eliminates many of the syscalls.
This flag needs some simple driver support. If the driver does not
support this, the Rx flag is always zero and the Tx flag is always
one. This makes any application relying on this feature default to the
old behaviour of not requiring any syscalls in the Rx path and always
having to call sendto() in the Tx path.
For backwards compatibility reasons, this feature has to be explicitly
turned on using a new bind flag (XDP_USE_NEED_WAKEUP). I recommend
that you always turn it on as it so far always have had a positive
performance impact.
The name and inspiration of the flag has been taken from io_uring by
Jens Axboe. Details about this feature in io_uring can be found in
http://kernel.dk/io_uring.pdf, section 8.3.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-14 15:27:17 +08:00
|
|
|
{
|
2020-08-28 16:26:19 +08:00
|
|
|
if (pool->cached_need_wakeup & XDP_WAKEUP_RX)
|
xsk: add support for need_wakeup flag in AF_XDP rings
This commit adds support for a new flag called need_wakeup in the
AF_XDP Tx and fill rings. When this flag is set, it means that the
application has to explicitly wake up the kernel Rx (for the bit in
the fill ring) or kernel Tx (for bit in the Tx ring) processing by
issuing a syscall. Poll() can wake up both depending on the flags
submitted and sendto() will wake up tx processing only.
The main reason for introducing this new flag is to be able to
efficiently support the case when application and driver is executing
on the same core. Previously, the driver was just busy-spinning on the
fill ring if it ran out of buffers in the HW and there were none on
the fill ring. This approach works when the application is running on
another core as it can replenish the fill ring while the driver is
busy-spinning. Though, this is a lousy approach if both of them are
running on the same core as the probability of the fill ring getting
more entries when the driver is busy-spinning is zero. With this new
feature the driver now sets the need_wakeup flag and returns to the
application. The application can then replenish the fill queue and
then explicitly wake up the Rx processing in the kernel using the
syscall poll(). For Tx, the flag is only set to one if the driver has
no outstanding Tx completion interrupts. If it has some, the flag is
zero as it will be woken up by a completion interrupt anyway.
As a nice side effect, this new flag also improves the performance of
the case where application and driver are running on two different
cores as it reduces the number of syscalls to the kernel. The kernel
tells user space if it needs to be woken up by a syscall, and this
eliminates many of the syscalls.
This flag needs some simple driver support. If the driver does not
support this, the Rx flag is always zero and the Tx flag is always
one. This makes any application relying on this feature default to the
old behaviour of not requiring any syscalls in the Rx path and always
having to call sendto() in the Tx path.
For backwards compatibility reasons, this feature has to be explicitly
turned on using a new bind flag (XDP_USE_NEED_WAKEUP). I recommend
that you always turn it on as it so far always have had a positive
performance impact.
The name and inspiration of the flag has been taken from io_uring by
Jens Axboe. Details about this feature in io_uring can be found in
http://kernel.dk/io_uring.pdf, section 8.3.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-14 15:27:17 +08:00
|
|
|
return;
|
|
|
|
|
2020-08-28 16:26:18 +08:00
|
|
|
pool->fq->ring->flags |= XDP_RING_NEED_WAKEUP;
|
2020-08-28 16:26:19 +08:00
|
|
|
pool->cached_need_wakeup |= XDP_WAKEUP_RX;
|
xsk: add support for need_wakeup flag in AF_XDP rings
This commit adds support for a new flag called need_wakeup in the
AF_XDP Tx and fill rings. When this flag is set, it means that the
application has to explicitly wake up the kernel Rx (for the bit in
the fill ring) or kernel Tx (for bit in the Tx ring) processing by
issuing a syscall. Poll() can wake up both depending on the flags
submitted and sendto() will wake up tx processing only.
The main reason for introducing this new flag is to be able to
efficiently support the case when application and driver is executing
on the same core. Previously, the driver was just busy-spinning on the
fill ring if it ran out of buffers in the HW and there were none on
the fill ring. This approach works when the application is running on
another core as it can replenish the fill ring while the driver is
busy-spinning. Though, this is a lousy approach if both of them are
running on the same core as the probability of the fill ring getting
more entries when the driver is busy-spinning is zero. With this new
feature the driver now sets the need_wakeup flag and returns to the
application. The application can then replenish the fill queue and
then explicitly wake up the Rx processing in the kernel using the
syscall poll(). For Tx, the flag is only set to one if the driver has
no outstanding Tx completion interrupts. If it has some, the flag is
zero as it will be woken up by a completion interrupt anyway.
As a nice side effect, this new flag also improves the performance of
the case where application and driver are running on two different
cores as it reduces the number of syscalls to the kernel. The kernel
tells user space if it needs to be woken up by a syscall, and this
eliminates many of the syscalls.
This flag needs some simple driver support. If the driver does not
support this, the Rx flag is always zero and the Tx flag is always
one. This makes any application relying on this feature default to the
old behaviour of not requiring any syscalls in the Rx path and always
having to call sendto() in the Tx path.
For backwards compatibility reasons, this feature has to be explicitly
turned on using a new bind flag (XDP_USE_NEED_WAKEUP). I recommend
that you always turn it on as it so far always have had a positive
performance impact.
The name and inspiration of the flag has been taken from io_uring by
Jens Axboe. Details about this feature in io_uring can be found in
http://kernel.dk/io_uring.pdf, section 8.3.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-14 15:27:17 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(xsk_set_rx_need_wakeup);
|
|
|
|
|
2020-08-28 16:26:16 +08:00
|
|
|
void xsk_set_tx_need_wakeup(struct xsk_buff_pool *pool)
|
xsk: add support for need_wakeup flag in AF_XDP rings
This commit adds support for a new flag called need_wakeup in the
AF_XDP Tx and fill rings. When this flag is set, it means that the
application has to explicitly wake up the kernel Rx (for the bit in
the fill ring) or kernel Tx (for bit in the Tx ring) processing by
issuing a syscall. Poll() can wake up both depending on the flags
submitted and sendto() will wake up tx processing only.
The main reason for introducing this new flag is to be able to
efficiently support the case when application and driver is executing
on the same core. Previously, the driver was just busy-spinning on the
fill ring if it ran out of buffers in the HW and there were none on
the fill ring. This approach works when the application is running on
another core as it can replenish the fill ring while the driver is
busy-spinning. Though, this is a lousy approach if both of them are
running on the same core as the probability of the fill ring getting
more entries when the driver is busy-spinning is zero. With this new
feature the driver now sets the need_wakeup flag and returns to the
application. The application can then replenish the fill queue and
then explicitly wake up the Rx processing in the kernel using the
syscall poll(). For Tx, the flag is only set to one if the driver has
no outstanding Tx completion interrupts. If it has some, the flag is
zero as it will be woken up by a completion interrupt anyway.
As a nice side effect, this new flag also improves the performance of
the case where application and driver are running on two different
cores as it reduces the number of syscalls to the kernel. The kernel
tells user space if it needs to be woken up by a syscall, and this
eliminates many of the syscalls.
This flag needs some simple driver support. If the driver does not
support this, the Rx flag is always zero and the Tx flag is always
one. This makes any application relying on this feature default to the
old behaviour of not requiring any syscalls in the Rx path and always
having to call sendto() in the Tx path.
For backwards compatibility reasons, this feature has to be explicitly
turned on using a new bind flag (XDP_USE_NEED_WAKEUP). I recommend
that you always turn it on as it so far always have had a positive
performance impact.
The name and inspiration of the flag has been taken from io_uring by
Jens Axboe. Details about this feature in io_uring can be found in
http://kernel.dk/io_uring.pdf, section 8.3.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-14 15:27:17 +08:00
|
|
|
{
|
|
|
|
struct xdp_sock *xs;
|
|
|
|
|
2020-08-28 16:26:19 +08:00
|
|
|
if (pool->cached_need_wakeup & XDP_WAKEUP_TX)
|
xsk: add support for need_wakeup flag in AF_XDP rings
This commit adds support for a new flag called need_wakeup in the
AF_XDP Tx and fill rings. When this flag is set, it means that the
application has to explicitly wake up the kernel Rx (for the bit in
the fill ring) or kernel Tx (for bit in the Tx ring) processing by
issuing a syscall. Poll() can wake up both depending on the flags
submitted and sendto() will wake up tx processing only.
The main reason for introducing this new flag is to be able to
efficiently support the case when application and driver is executing
on the same core. Previously, the driver was just busy-spinning on the
fill ring if it ran out of buffers in the HW and there were none on
the fill ring. This approach works when the application is running on
another core as it can replenish the fill ring while the driver is
busy-spinning. Though, this is a lousy approach if both of them are
running on the same core as the probability of the fill ring getting
more entries when the driver is busy-spinning is zero. With this new
feature the driver now sets the need_wakeup flag and returns to the
application. The application can then replenish the fill queue and
then explicitly wake up the Rx processing in the kernel using the
syscall poll(). For Tx, the flag is only set to one if the driver has
no outstanding Tx completion interrupts. If it has some, the flag is
zero as it will be woken up by a completion interrupt anyway.
As a nice side effect, this new flag also improves the performance of
the case where application and driver are running on two different
cores as it reduces the number of syscalls to the kernel. The kernel
tells user space if it needs to be woken up by a syscall, and this
eliminates many of the syscalls.
This flag needs some simple driver support. If the driver does not
support this, the Rx flag is always zero and the Tx flag is always
one. This makes any application relying on this feature default to the
old behaviour of not requiring any syscalls in the Rx path and always
having to call sendto() in the Tx path.
For backwards compatibility reasons, this feature has to be explicitly
turned on using a new bind flag (XDP_USE_NEED_WAKEUP). I recommend
that you always turn it on as it so far always have had a positive
performance impact.
The name and inspiration of the flag has been taken from io_uring by
Jens Axboe. Details about this feature in io_uring can be found in
http://kernel.dk/io_uring.pdf, section 8.3.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-14 15:27:17 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
2020-08-28 16:26:20 +08:00
|
|
|
list_for_each_entry_rcu(xs, &pool->xsk_tx_list, tx_list) {
|
xsk: add support for need_wakeup flag in AF_XDP rings
This commit adds support for a new flag called need_wakeup in the
AF_XDP Tx and fill rings. When this flag is set, it means that the
application has to explicitly wake up the kernel Rx (for the bit in
the fill ring) or kernel Tx (for bit in the Tx ring) processing by
issuing a syscall. Poll() can wake up both depending on the flags
submitted and sendto() will wake up tx processing only.
The main reason for introducing this new flag is to be able to
efficiently support the case when application and driver is executing
on the same core. Previously, the driver was just busy-spinning on the
fill ring if it ran out of buffers in the HW and there were none on
the fill ring. This approach works when the application is running on
another core as it can replenish the fill ring while the driver is
busy-spinning. Though, this is a lousy approach if both of them are
running on the same core as the probability of the fill ring getting
more entries when the driver is busy-spinning is zero. With this new
feature the driver now sets the need_wakeup flag and returns to the
application. The application can then replenish the fill queue and
then explicitly wake up the Rx processing in the kernel using the
syscall poll(). For Tx, the flag is only set to one if the driver has
no outstanding Tx completion interrupts. If it has some, the flag is
zero as it will be woken up by a completion interrupt anyway.
As a nice side effect, this new flag also improves the performance of
the case where application and driver are running on two different
cores as it reduces the number of syscalls to the kernel. The kernel
tells user space if it needs to be woken up by a syscall, and this
eliminates many of the syscalls.
This flag needs some simple driver support. If the driver does not
support this, the Rx flag is always zero and the Tx flag is always
one. This makes any application relying on this feature default to the
old behaviour of not requiring any syscalls in the Rx path and always
having to call sendto() in the Tx path.
For backwards compatibility reasons, this feature has to be explicitly
turned on using a new bind flag (XDP_USE_NEED_WAKEUP). I recommend
that you always turn it on as it so far always have had a positive
performance impact.
The name and inspiration of the flag has been taken from io_uring by
Jens Axboe. Details about this feature in io_uring can be found in
http://kernel.dk/io_uring.pdf, section 8.3.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-14 15:27:17 +08:00
|
|
|
xs->tx->ring->flags |= XDP_RING_NEED_WAKEUP;
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
2020-08-28 16:26:19 +08:00
|
|
|
pool->cached_need_wakeup |= XDP_WAKEUP_TX;
|
xsk: add support for need_wakeup flag in AF_XDP rings
This commit adds support for a new flag called need_wakeup in the
AF_XDP Tx and fill rings. When this flag is set, it means that the
application has to explicitly wake up the kernel Rx (for the bit in
the fill ring) or kernel Tx (for bit in the Tx ring) processing by
issuing a syscall. Poll() can wake up both depending on the flags
submitted and sendto() will wake up tx processing only.
The main reason for introducing this new flag is to be able to
efficiently support the case when application and driver is executing
on the same core. Previously, the driver was just busy-spinning on the
fill ring if it ran out of buffers in the HW and there were none on
the fill ring. This approach works when the application is running on
another core as it can replenish the fill ring while the driver is
busy-spinning. Though, this is a lousy approach if both of them are
running on the same core as the probability of the fill ring getting
more entries when the driver is busy-spinning is zero. With this new
feature the driver now sets the need_wakeup flag and returns to the
application. The application can then replenish the fill queue and
then explicitly wake up the Rx processing in the kernel using the
syscall poll(). For Tx, the flag is only set to one if the driver has
no outstanding Tx completion interrupts. If it has some, the flag is
zero as it will be woken up by a completion interrupt anyway.
As a nice side effect, this new flag also improves the performance of
the case where application and driver are running on two different
cores as it reduces the number of syscalls to the kernel. The kernel
tells user space if it needs to be woken up by a syscall, and this
eliminates many of the syscalls.
This flag needs some simple driver support. If the driver does not
support this, the Rx flag is always zero and the Tx flag is always
one. This makes any application relying on this feature default to the
old behaviour of not requiring any syscalls in the Rx path and always
having to call sendto() in the Tx path.
For backwards compatibility reasons, this feature has to be explicitly
turned on using a new bind flag (XDP_USE_NEED_WAKEUP). I recommend
that you always turn it on as it so far always have had a positive
performance impact.
The name and inspiration of the flag has been taken from io_uring by
Jens Axboe. Details about this feature in io_uring can be found in
http://kernel.dk/io_uring.pdf, section 8.3.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-14 15:27:17 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(xsk_set_tx_need_wakeup);
|
|
|
|
|
2020-08-28 16:26:16 +08:00
|
|
|
void xsk_clear_rx_need_wakeup(struct xsk_buff_pool *pool)
|
xsk: add support for need_wakeup flag in AF_XDP rings
This commit adds support for a new flag called need_wakeup in the
AF_XDP Tx and fill rings. When this flag is set, it means that the
application has to explicitly wake up the kernel Rx (for the bit in
the fill ring) or kernel Tx (for bit in the Tx ring) processing by
issuing a syscall. Poll() can wake up both depending on the flags
submitted and sendto() will wake up tx processing only.
The main reason for introducing this new flag is to be able to
efficiently support the case when application and driver is executing
on the same core. Previously, the driver was just busy-spinning on the
fill ring if it ran out of buffers in the HW and there were none on
the fill ring. This approach works when the application is running on
another core as it can replenish the fill ring while the driver is
busy-spinning. Though, this is a lousy approach if both of them are
running on the same core as the probability of the fill ring getting
more entries when the driver is busy-spinning is zero. With this new
feature the driver now sets the need_wakeup flag and returns to the
application. The application can then replenish the fill queue and
then explicitly wake up the Rx processing in the kernel using the
syscall poll(). For Tx, the flag is only set to one if the driver has
no outstanding Tx completion interrupts. If it has some, the flag is
zero as it will be woken up by a completion interrupt anyway.
As a nice side effect, this new flag also improves the performance of
the case where application and driver are running on two different
cores as it reduces the number of syscalls to the kernel. The kernel
tells user space if it needs to be woken up by a syscall, and this
eliminates many of the syscalls.
This flag needs some simple driver support. If the driver does not
support this, the Rx flag is always zero and the Tx flag is always
one. This makes any application relying on this feature default to the
old behaviour of not requiring any syscalls in the Rx path and always
having to call sendto() in the Tx path.
For backwards compatibility reasons, this feature has to be explicitly
turned on using a new bind flag (XDP_USE_NEED_WAKEUP). I recommend
that you always turn it on as it so far always have had a positive
performance impact.
The name and inspiration of the flag has been taken from io_uring by
Jens Axboe. Details about this feature in io_uring can be found in
http://kernel.dk/io_uring.pdf, section 8.3.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-14 15:27:17 +08:00
|
|
|
{
|
2020-08-28 16:26:19 +08:00
|
|
|
if (!(pool->cached_need_wakeup & XDP_WAKEUP_RX))
|
xsk: add support for need_wakeup flag in AF_XDP rings
This commit adds support for a new flag called need_wakeup in the
AF_XDP Tx and fill rings. When this flag is set, it means that the
application has to explicitly wake up the kernel Rx (for the bit in
the fill ring) or kernel Tx (for bit in the Tx ring) processing by
issuing a syscall. Poll() can wake up both depending on the flags
submitted and sendto() will wake up tx processing only.
The main reason for introducing this new flag is to be able to
efficiently support the case when application and driver is executing
on the same core. Previously, the driver was just busy-spinning on the
fill ring if it ran out of buffers in the HW and there were none on
the fill ring. This approach works when the application is running on
another core as it can replenish the fill ring while the driver is
busy-spinning. Though, this is a lousy approach if both of them are
running on the same core as the probability of the fill ring getting
more entries when the driver is busy-spinning is zero. With this new
feature the driver now sets the need_wakeup flag and returns to the
application. The application can then replenish the fill queue and
then explicitly wake up the Rx processing in the kernel using the
syscall poll(). For Tx, the flag is only set to one if the driver has
no outstanding Tx completion interrupts. If it has some, the flag is
zero as it will be woken up by a completion interrupt anyway.
As a nice side effect, this new flag also improves the performance of
the case where application and driver are running on two different
cores as it reduces the number of syscalls to the kernel. The kernel
tells user space if it needs to be woken up by a syscall, and this
eliminates many of the syscalls.
This flag needs some simple driver support. If the driver does not
support this, the Rx flag is always zero and the Tx flag is always
one. This makes any application relying on this feature default to the
old behaviour of not requiring any syscalls in the Rx path and always
having to call sendto() in the Tx path.
For backwards compatibility reasons, this feature has to be explicitly
turned on using a new bind flag (XDP_USE_NEED_WAKEUP). I recommend
that you always turn it on as it so far always have had a positive
performance impact.
The name and inspiration of the flag has been taken from io_uring by
Jens Axboe. Details about this feature in io_uring can be found in
http://kernel.dk/io_uring.pdf, section 8.3.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-14 15:27:17 +08:00
|
|
|
return;
|
|
|
|
|
2020-08-28 16:26:18 +08:00
|
|
|
pool->fq->ring->flags &= ~XDP_RING_NEED_WAKEUP;
|
2020-08-28 16:26:19 +08:00
|
|
|
pool->cached_need_wakeup &= ~XDP_WAKEUP_RX;
|
xsk: add support for need_wakeup flag in AF_XDP rings
This commit adds support for a new flag called need_wakeup in the
AF_XDP Tx and fill rings. When this flag is set, it means that the
application has to explicitly wake up the kernel Rx (for the bit in
the fill ring) or kernel Tx (for bit in the Tx ring) processing by
issuing a syscall. Poll() can wake up both depending on the flags
submitted and sendto() will wake up tx processing only.
The main reason for introducing this new flag is to be able to
efficiently support the case when application and driver is executing
on the same core. Previously, the driver was just busy-spinning on the
fill ring if it ran out of buffers in the HW and there were none on
the fill ring. This approach works when the application is running on
another core as it can replenish the fill ring while the driver is
busy-spinning. Though, this is a lousy approach if both of them are
running on the same core as the probability of the fill ring getting
more entries when the driver is busy-spinning is zero. With this new
feature the driver now sets the need_wakeup flag and returns to the
application. The application can then replenish the fill queue and
then explicitly wake up the Rx processing in the kernel using the
syscall poll(). For Tx, the flag is only set to one if the driver has
no outstanding Tx completion interrupts. If it has some, the flag is
zero as it will be woken up by a completion interrupt anyway.
As a nice side effect, this new flag also improves the performance of
the case where application and driver are running on two different
cores as it reduces the number of syscalls to the kernel. The kernel
tells user space if it needs to be woken up by a syscall, and this
eliminates many of the syscalls.
This flag needs some simple driver support. If the driver does not
support this, the Rx flag is always zero and the Tx flag is always
one. This makes any application relying on this feature default to the
old behaviour of not requiring any syscalls in the Rx path and always
having to call sendto() in the Tx path.
For backwards compatibility reasons, this feature has to be explicitly
turned on using a new bind flag (XDP_USE_NEED_WAKEUP). I recommend
that you always turn it on as it so far always have had a positive
performance impact.
The name and inspiration of the flag has been taken from io_uring by
Jens Axboe. Details about this feature in io_uring can be found in
http://kernel.dk/io_uring.pdf, section 8.3.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-14 15:27:17 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(xsk_clear_rx_need_wakeup);
|
|
|
|
|
2020-08-28 16:26:16 +08:00
|
|
|
void xsk_clear_tx_need_wakeup(struct xsk_buff_pool *pool)
|
xsk: add support for need_wakeup flag in AF_XDP rings
This commit adds support for a new flag called need_wakeup in the
AF_XDP Tx and fill rings. When this flag is set, it means that the
application has to explicitly wake up the kernel Rx (for the bit in
the fill ring) or kernel Tx (for bit in the Tx ring) processing by
issuing a syscall. Poll() can wake up both depending on the flags
submitted and sendto() will wake up tx processing only.
The main reason for introducing this new flag is to be able to
efficiently support the case when application and driver is executing
on the same core. Previously, the driver was just busy-spinning on the
fill ring if it ran out of buffers in the HW and there were none on
the fill ring. This approach works when the application is running on
another core as it can replenish the fill ring while the driver is
busy-spinning. Though, this is a lousy approach if both of them are
running on the same core as the probability of the fill ring getting
more entries when the driver is busy-spinning is zero. With this new
feature the driver now sets the need_wakeup flag and returns to the
application. The application can then replenish the fill queue and
then explicitly wake up the Rx processing in the kernel using the
syscall poll(). For Tx, the flag is only set to one if the driver has
no outstanding Tx completion interrupts. If it has some, the flag is
zero as it will be woken up by a completion interrupt anyway.
As a nice side effect, this new flag also improves the performance of
the case where application and driver are running on two different
cores as it reduces the number of syscalls to the kernel. The kernel
tells user space if it needs to be woken up by a syscall, and this
eliminates many of the syscalls.
This flag needs some simple driver support. If the driver does not
support this, the Rx flag is always zero and the Tx flag is always
one. This makes any application relying on this feature default to the
old behaviour of not requiring any syscalls in the Rx path and always
having to call sendto() in the Tx path.
For backwards compatibility reasons, this feature has to be explicitly
turned on using a new bind flag (XDP_USE_NEED_WAKEUP). I recommend
that you always turn it on as it so far always have had a positive
performance impact.
The name and inspiration of the flag has been taken from io_uring by
Jens Axboe. Details about this feature in io_uring can be found in
http://kernel.dk/io_uring.pdf, section 8.3.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-14 15:27:17 +08:00
|
|
|
{
|
|
|
|
struct xdp_sock *xs;
|
|
|
|
|
2020-08-28 16:26:19 +08:00
|
|
|
if (!(pool->cached_need_wakeup & XDP_WAKEUP_TX))
|
xsk: add support for need_wakeup flag in AF_XDP rings
This commit adds support for a new flag called need_wakeup in the
AF_XDP Tx and fill rings. When this flag is set, it means that the
application has to explicitly wake up the kernel Rx (for the bit in
the fill ring) or kernel Tx (for bit in the Tx ring) processing by
issuing a syscall. Poll() can wake up both depending on the flags
submitted and sendto() will wake up tx processing only.
The main reason for introducing this new flag is to be able to
efficiently support the case when application and driver is executing
on the same core. Previously, the driver was just busy-spinning on the
fill ring if it ran out of buffers in the HW and there were none on
the fill ring. This approach works when the application is running on
another core as it can replenish the fill ring while the driver is
busy-spinning. Though, this is a lousy approach if both of them are
running on the same core as the probability of the fill ring getting
more entries when the driver is busy-spinning is zero. With this new
feature the driver now sets the need_wakeup flag and returns to the
application. The application can then replenish the fill queue and
then explicitly wake up the Rx processing in the kernel using the
syscall poll(). For Tx, the flag is only set to one if the driver has
no outstanding Tx completion interrupts. If it has some, the flag is
zero as it will be woken up by a completion interrupt anyway.
As a nice side effect, this new flag also improves the performance of
the case where application and driver are running on two different
cores as it reduces the number of syscalls to the kernel. The kernel
tells user space if it needs to be woken up by a syscall, and this
eliminates many of the syscalls.
This flag needs some simple driver support. If the driver does not
support this, the Rx flag is always zero and the Tx flag is always
one. This makes any application relying on this feature default to the
old behaviour of not requiring any syscalls in the Rx path and always
having to call sendto() in the Tx path.
For backwards compatibility reasons, this feature has to be explicitly
turned on using a new bind flag (XDP_USE_NEED_WAKEUP). I recommend
that you always turn it on as it so far always have had a positive
performance impact.
The name and inspiration of the flag has been taken from io_uring by
Jens Axboe. Details about this feature in io_uring can be found in
http://kernel.dk/io_uring.pdf, section 8.3.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-14 15:27:17 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
2020-08-28 16:26:20 +08:00
|
|
|
list_for_each_entry_rcu(xs, &pool->xsk_tx_list, tx_list) {
|
xsk: add support for need_wakeup flag in AF_XDP rings
This commit adds support for a new flag called need_wakeup in the
AF_XDP Tx and fill rings. When this flag is set, it means that the
application has to explicitly wake up the kernel Rx (for the bit in
the fill ring) or kernel Tx (for bit in the Tx ring) processing by
issuing a syscall. Poll() can wake up both depending on the flags
submitted and sendto() will wake up tx processing only.
The main reason for introducing this new flag is to be able to
efficiently support the case when application and driver is executing
on the same core. Previously, the driver was just busy-spinning on the
fill ring if it ran out of buffers in the HW and there were none on
the fill ring. This approach works when the application is running on
another core as it can replenish the fill ring while the driver is
busy-spinning. Though, this is a lousy approach if both of them are
running on the same core as the probability of the fill ring getting
more entries when the driver is busy-spinning is zero. With this new
feature the driver now sets the need_wakeup flag and returns to the
application. The application can then replenish the fill queue and
then explicitly wake up the Rx processing in the kernel using the
syscall poll(). For Tx, the flag is only set to one if the driver has
no outstanding Tx completion interrupts. If it has some, the flag is
zero as it will be woken up by a completion interrupt anyway.
As a nice side effect, this new flag also improves the performance of
the case where application and driver are running on two different
cores as it reduces the number of syscalls to the kernel. The kernel
tells user space if it needs to be woken up by a syscall, and this
eliminates many of the syscalls.
This flag needs some simple driver support. If the driver does not
support this, the Rx flag is always zero and the Tx flag is always
one. This makes any application relying on this feature default to the
old behaviour of not requiring any syscalls in the Rx path and always
having to call sendto() in the Tx path.
For backwards compatibility reasons, this feature has to be explicitly
turned on using a new bind flag (XDP_USE_NEED_WAKEUP). I recommend
that you always turn it on as it so far always have had a positive
performance impact.
The name and inspiration of the flag has been taken from io_uring by
Jens Axboe. Details about this feature in io_uring can be found in
http://kernel.dk/io_uring.pdf, section 8.3.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-14 15:27:17 +08:00
|
|
|
xs->tx->ring->flags &= ~XDP_RING_NEED_WAKEUP;
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
2020-08-28 16:26:19 +08:00
|
|
|
pool->cached_need_wakeup &= ~XDP_WAKEUP_TX;
|
xsk: add support for need_wakeup flag in AF_XDP rings
This commit adds support for a new flag called need_wakeup in the
AF_XDP Tx and fill rings. When this flag is set, it means that the
application has to explicitly wake up the kernel Rx (for the bit in
the fill ring) or kernel Tx (for bit in the Tx ring) processing by
issuing a syscall. Poll() can wake up both depending on the flags
submitted and sendto() will wake up tx processing only.
The main reason for introducing this new flag is to be able to
efficiently support the case when application and driver is executing
on the same core. Previously, the driver was just busy-spinning on the
fill ring if it ran out of buffers in the HW and there were none on
the fill ring. This approach works when the application is running on
another core as it can replenish the fill ring while the driver is
busy-spinning. Though, this is a lousy approach if both of them are
running on the same core as the probability of the fill ring getting
more entries when the driver is busy-spinning is zero. With this new
feature the driver now sets the need_wakeup flag and returns to the
application. The application can then replenish the fill queue and
then explicitly wake up the Rx processing in the kernel using the
syscall poll(). For Tx, the flag is only set to one if the driver has
no outstanding Tx completion interrupts. If it has some, the flag is
zero as it will be woken up by a completion interrupt anyway.
As a nice side effect, this new flag also improves the performance of
the case where application and driver are running on two different
cores as it reduces the number of syscalls to the kernel. The kernel
tells user space if it needs to be woken up by a syscall, and this
eliminates many of the syscalls.
This flag needs some simple driver support. If the driver does not
support this, the Rx flag is always zero and the Tx flag is always
one. This makes any application relying on this feature default to the
old behaviour of not requiring any syscalls in the Rx path and always
having to call sendto() in the Tx path.
For backwards compatibility reasons, this feature has to be explicitly
turned on using a new bind flag (XDP_USE_NEED_WAKEUP). I recommend
that you always turn it on as it so far always have had a positive
performance impact.
The name and inspiration of the flag has been taken from io_uring by
Jens Axboe. Details about this feature in io_uring can be found in
http://kernel.dk/io_uring.pdf, section 8.3.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-14 15:27:17 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(xsk_clear_tx_need_wakeup);
|
|
|
|
|
2020-08-28 16:26:16 +08:00
|
|
|
bool xsk_uses_need_wakeup(struct xsk_buff_pool *pool)
|
xsk: add support for need_wakeup flag in AF_XDP rings
This commit adds support for a new flag called need_wakeup in the
AF_XDP Tx and fill rings. When this flag is set, it means that the
application has to explicitly wake up the kernel Rx (for the bit in
the fill ring) or kernel Tx (for bit in the Tx ring) processing by
issuing a syscall. Poll() can wake up both depending on the flags
submitted and sendto() will wake up tx processing only.
The main reason for introducing this new flag is to be able to
efficiently support the case when application and driver is executing
on the same core. Previously, the driver was just busy-spinning on the
fill ring if it ran out of buffers in the HW and there were none on
the fill ring. This approach works when the application is running on
another core as it can replenish the fill ring while the driver is
busy-spinning. Though, this is a lousy approach if both of them are
running on the same core as the probability of the fill ring getting
more entries when the driver is busy-spinning is zero. With this new
feature the driver now sets the need_wakeup flag and returns to the
application. The application can then replenish the fill queue and
then explicitly wake up the Rx processing in the kernel using the
syscall poll(). For Tx, the flag is only set to one if the driver has
no outstanding Tx completion interrupts. If it has some, the flag is
zero as it will be woken up by a completion interrupt anyway.
As a nice side effect, this new flag also improves the performance of
the case where application and driver are running on two different
cores as it reduces the number of syscalls to the kernel. The kernel
tells user space if it needs to be woken up by a syscall, and this
eliminates many of the syscalls.
This flag needs some simple driver support. If the driver does not
support this, the Rx flag is always zero and the Tx flag is always
one. This makes any application relying on this feature default to the
old behaviour of not requiring any syscalls in the Rx path and always
having to call sendto() in the Tx path.
For backwards compatibility reasons, this feature has to be explicitly
turned on using a new bind flag (XDP_USE_NEED_WAKEUP). I recommend
that you always turn it on as it so far always have had a positive
performance impact.
The name and inspiration of the flag has been taken from io_uring by
Jens Axboe. Details about this feature in io_uring can be found in
http://kernel.dk/io_uring.pdf, section 8.3.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-14 15:27:17 +08:00
|
|
|
{
|
2020-08-28 16:26:19 +08:00
|
|
|
return pool->uses_need_wakeup;
|
xsk: add support for need_wakeup flag in AF_XDP rings
This commit adds support for a new flag called need_wakeup in the
AF_XDP Tx and fill rings. When this flag is set, it means that the
application has to explicitly wake up the kernel Rx (for the bit in
the fill ring) or kernel Tx (for bit in the Tx ring) processing by
issuing a syscall. Poll() can wake up both depending on the flags
submitted and sendto() will wake up tx processing only.
The main reason for introducing this new flag is to be able to
efficiently support the case when application and driver is executing
on the same core. Previously, the driver was just busy-spinning on the
fill ring if it ran out of buffers in the HW and there were none on
the fill ring. This approach works when the application is running on
another core as it can replenish the fill ring while the driver is
busy-spinning. Though, this is a lousy approach if both of them are
running on the same core as the probability of the fill ring getting
more entries when the driver is busy-spinning is zero. With this new
feature the driver now sets the need_wakeup flag and returns to the
application. The application can then replenish the fill queue and
then explicitly wake up the Rx processing in the kernel using the
syscall poll(). For Tx, the flag is only set to one if the driver has
no outstanding Tx completion interrupts. If it has some, the flag is
zero as it will be woken up by a completion interrupt anyway.
As a nice side effect, this new flag also improves the performance of
the case where application and driver are running on two different
cores as it reduces the number of syscalls to the kernel. The kernel
tells user space if it needs to be woken up by a syscall, and this
eliminates many of the syscalls.
This flag needs some simple driver support. If the driver does not
support this, the Rx flag is always zero and the Tx flag is always
one. This makes any application relying on this feature default to the
old behaviour of not requiring any syscalls in the Rx path and always
having to call sendto() in the Tx path.
For backwards compatibility reasons, this feature has to be explicitly
turned on using a new bind flag (XDP_USE_NEED_WAKEUP). I recommend
that you always turn it on as it so far always have had a positive
performance impact.
The name and inspiration of the flag has been taken from io_uring by
Jens Axboe. Details about this feature in io_uring can be found in
http://kernel.dk/io_uring.pdf, section 8.3.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-14 15:27:17 +08:00
|
|
|
}
|
2020-08-28 16:26:16 +08:00
|
|
|
EXPORT_SYMBOL(xsk_uses_need_wakeup);
|
xsk: add support for need_wakeup flag in AF_XDP rings
This commit adds support for a new flag called need_wakeup in the
AF_XDP Tx and fill rings. When this flag is set, it means that the
application has to explicitly wake up the kernel Rx (for the bit in
the fill ring) or kernel Tx (for bit in the Tx ring) processing by
issuing a syscall. Poll() can wake up both depending on the flags
submitted and sendto() will wake up tx processing only.
The main reason for introducing this new flag is to be able to
efficiently support the case when application and driver is executing
on the same core. Previously, the driver was just busy-spinning on the
fill ring if it ran out of buffers in the HW and there were none on
the fill ring. This approach works when the application is running on
another core as it can replenish the fill ring while the driver is
busy-spinning. Though, this is a lousy approach if both of them are
running on the same core as the probability of the fill ring getting
more entries when the driver is busy-spinning is zero. With this new
feature the driver now sets the need_wakeup flag and returns to the
application. The application can then replenish the fill queue and
then explicitly wake up the Rx processing in the kernel using the
syscall poll(). For Tx, the flag is only set to one if the driver has
no outstanding Tx completion interrupts. If it has some, the flag is
zero as it will be woken up by a completion interrupt anyway.
As a nice side effect, this new flag also improves the performance of
the case where application and driver are running on two different
cores as it reduces the number of syscalls to the kernel. The kernel
tells user space if it needs to be woken up by a syscall, and this
eliminates many of the syscalls.
This flag needs some simple driver support. If the driver does not
support this, the Rx flag is always zero and the Tx flag is always
one. This makes any application relying on this feature default to the
old behaviour of not requiring any syscalls in the Rx path and always
having to call sendto() in the Tx path.
For backwards compatibility reasons, this feature has to be explicitly
turned on using a new bind flag (XDP_USE_NEED_WAKEUP). I recommend
that you always turn it on as it so far always have had a positive
performance impact.
The name and inspiration of the flag has been taken from io_uring by
Jens Axboe. Details about this feature in io_uring can be found in
http://kernel.dk/io_uring.pdf, section 8.3.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-14 15:27:17 +08:00
|
|
|
|
2020-08-28 16:26:17 +08:00
|
|
|
struct xsk_buff_pool *xsk_get_pool_from_qid(struct net_device *dev,
|
|
|
|
u16 queue_id)
|
|
|
|
{
|
|
|
|
if (queue_id < dev->real_num_rx_queues)
|
|
|
|
return dev->_rx[queue_id].pool;
|
|
|
|
if (queue_id < dev->real_num_tx_queues)
|
|
|
|
return dev->_tx[queue_id].pool;
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(xsk_get_pool_from_qid);
|
|
|
|
|
|
|
|
void xsk_clear_pool_at_qid(struct net_device *dev, u16 queue_id)
|
|
|
|
{
|
xsk: Clear pool even for inactive queues
The number of queues can change by other means, rather than ethtool. For
example, attaching an mqprio qdisc with num_tc > 1 leads to creating
multiple sets of TX queues, which may be then destroyed when mqprio is
deleted. If an AF_XDP socket is created while mqprio is active,
dev->_tx[queue_id].pool will be filled, but then real_num_tx_queues may
decrease with deletion of mqprio, which will mean that the pool won't be
NULLed, and a further increase of the number of TX queues may expose a
dangling pointer.
To avoid any potential misbehavior, this commit clears pool for RX and
TX queues, regardless of real_num_*_queues, still taking into
consideration num_*_queues to avoid overflows.
Fixes: 1c1efc2af158 ("xsk: Create and free buffer pool independently from umem")
Fixes: a41b4f3c58dd ("xsk: simplify xdp_clear_umem_at_qid implementation")
Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Björn Töpel <bjorn.topel@intel.com>
Link: https://lore.kernel.org/bpf/20210118160333.333439-1-maximmi@mellanox.com
2021-01-19 00:03:33 +08:00
|
|
|
if (queue_id < dev->num_rx_queues)
|
2020-08-28 16:26:17 +08:00
|
|
|
dev->_rx[queue_id].pool = NULL;
|
xsk: Clear pool even for inactive queues
The number of queues can change by other means, rather than ethtool. For
example, attaching an mqprio qdisc with num_tc > 1 leads to creating
multiple sets of TX queues, which may be then destroyed when mqprio is
deleted. If an AF_XDP socket is created while mqprio is active,
dev->_tx[queue_id].pool will be filled, but then real_num_tx_queues may
decrease with deletion of mqprio, which will mean that the pool won't be
NULLed, and a further increase of the number of TX queues may expose a
dangling pointer.
To avoid any potential misbehavior, this commit clears pool for RX and
TX queues, regardless of real_num_*_queues, still taking into
consideration num_*_queues to avoid overflows.
Fixes: 1c1efc2af158 ("xsk: Create and free buffer pool independently from umem")
Fixes: a41b4f3c58dd ("xsk: simplify xdp_clear_umem_at_qid implementation")
Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Björn Töpel <bjorn.topel@intel.com>
Link: https://lore.kernel.org/bpf/20210118160333.333439-1-maximmi@mellanox.com
2021-01-19 00:03:33 +08:00
|
|
|
if (queue_id < dev->num_tx_queues)
|
2020-08-28 16:26:17 +08:00
|
|
|
dev->_tx[queue_id].pool = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* The buffer pool is stored both in the _rx struct and the _tx struct as we do
|
|
|
|
* not know if the device has more tx queues than rx, or the opposite.
|
|
|
|
* This might also change during run time.
|
|
|
|
*/
|
|
|
|
int xsk_reg_pool_at_qid(struct net_device *dev, struct xsk_buff_pool *pool,
|
|
|
|
u16 queue_id)
|
|
|
|
{
|
|
|
|
if (queue_id >= max_t(unsigned int,
|
|
|
|
dev->real_num_rx_queues,
|
|
|
|
dev->real_num_tx_queues))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (queue_id < dev->real_num_rx_queues)
|
|
|
|
dev->_rx[queue_id].pool = pool;
|
|
|
|
if (queue_id < dev->real_num_tx_queues)
|
|
|
|
dev->_tx[queue_id].pool = pool;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-05-21 03:20:53 +08:00
|
|
|
static int __xsk_rcv_zc(struct xdp_sock *xs, struct xdp_buff *xdp, u32 len)
|
xsk: add support to allow unaligned chunk placement
Currently, addresses are chunk size aligned. This means, we are very
restricted in terms of where we can place chunk within the umem. For
example, if we have a chunk size of 2k, then our chunks can only be placed
at 0,2k,4k,6k,8k... and so on (ie. every 2k starting from 0).
This patch introduces the ability to use unaligned chunks. With these
changes, we are no longer bound to having to place chunks at a 2k (or
whatever your chunk size is) interval. Since we are no longer dealing with
aligned chunks, they can now cross page boundaries. Checks for page
contiguity have been added in order to keep track of which pages are
followed by a physically contiguous page.
Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-27 10:25:22 +08:00
|
|
|
{
|
2020-05-21 03:20:53 +08:00
|
|
|
struct xdp_buff_xsk *xskb = container_of(xdp, struct xdp_buff_xsk, xdp);
|
|
|
|
u64 addr;
|
|
|
|
int err;
|
xsk: add support to allow unaligned chunk placement
Currently, addresses are chunk size aligned. This means, we are very
restricted in terms of where we can place chunk within the umem. For
example, if we have a chunk size of 2k, then our chunks can only be placed
at 0,2k,4k,6k,8k... and so on (ie. every 2k starting from 0).
This patch introduces the ability to use unaligned chunks. With these
changes, we are no longer bound to having to place chunks at a 2k (or
whatever your chunk size is) interval. Since we are no longer dealing with
aligned chunks, they can now cross page boundaries. Checks for page
contiguity have been added in order to keep track of which pages are
followed by a physically contiguous page.
Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-27 10:25:22 +08:00
|
|
|
|
2020-05-21 03:20:53 +08:00
|
|
|
addr = xp_get_handle(xskb);
|
|
|
|
err = xskq_prod_reserve_desc(xs->rx, addr, len);
|
|
|
|
if (err) {
|
2020-07-08 15:28:33 +08:00
|
|
|
xs->rx_queue_full++;
|
2020-05-21 03:20:53 +08:00
|
|
|
return err;
|
xsk: add support to allow unaligned chunk placement
Currently, addresses are chunk size aligned. This means, we are very
restricted in terms of where we can place chunk within the umem. For
example, if we have a chunk size of 2k, then our chunks can only be placed
at 0,2k,4k,6k,8k... and so on (ie. every 2k starting from 0).
This patch introduces the ability to use unaligned chunks. With these
changes, we are no longer bound to having to place chunks at a 2k (or
whatever your chunk size is) interval. Since we are no longer dealing with
aligned chunks, they can now cross page boundaries. Checks for page
contiguity have been added in order to keep track of which pages are
followed by a physically contiguous page.
Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-27 10:25:22 +08:00
|
|
|
}
|
|
|
|
|
2020-05-21 03:20:53 +08:00
|
|
|
xp_release(xskb);
|
|
|
|
return 0;
|
xsk: add support to allow unaligned chunk placement
Currently, addresses are chunk size aligned. This means, we are very
restricted in terms of where we can place chunk within the umem. For
example, if we have a chunk size of 2k, then our chunks can only be placed
at 0,2k,4k,6k,8k... and so on (ie. every 2k starting from 0).
This patch introduces the ability to use unaligned chunks. With these
changes, we are no longer bound to having to place chunks at a 2k (or
whatever your chunk size is) interval. Since we are no longer dealing with
aligned chunks, they can now cross page boundaries. Checks for page
contiguity have been added in order to keep track of which pages are
followed by a physically contiguous page.
Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-27 10:25:22 +08:00
|
|
|
}
|
|
|
|
|
2020-05-21 03:20:53 +08:00
|
|
|
static void xsk_copy_xdp(struct xdp_buff *to, struct xdp_buff *from, u32 len)
|
2018-05-02 19:01:27 +08:00
|
|
|
{
|
2020-05-21 03:20:53 +08:00
|
|
|
void *from_buf, *to_buf;
|
2018-08-30 21:12:48 +08:00
|
|
|
u32 metalen;
|
2018-05-02 19:01:27 +08:00
|
|
|
|
2020-05-21 03:20:53 +08:00
|
|
|
if (unlikely(xdp_data_meta_unsupported(from))) {
|
|
|
|
from_buf = from->data;
|
|
|
|
to_buf = to->data;
|
2018-08-30 21:12:48 +08:00
|
|
|
metalen = 0;
|
|
|
|
} else {
|
2020-05-21 03:20:53 +08:00
|
|
|
from_buf = from->data_meta;
|
|
|
|
metalen = from->data - from->data_meta;
|
|
|
|
to_buf = to->data - metalen;
|
2018-08-30 21:12:48 +08:00
|
|
|
}
|
|
|
|
|
2020-05-21 03:20:53 +08:00
|
|
|
memcpy(to_buf, from_buf, len + metalen);
|
2018-05-02 19:01:27 +08:00
|
|
|
}
|
|
|
|
|
2021-01-22 18:53:49 +08:00
|
|
|
static int __xsk_rcv(struct xdp_sock *xs, struct xdp_buff *xdp)
|
2018-05-02 19:01:27 +08:00
|
|
|
{
|
2020-05-21 03:20:53 +08:00
|
|
|
struct xdp_buff *xsk_xdp;
|
|
|
|
int err;
|
2021-01-22 18:53:49 +08:00
|
|
|
u32 len;
|
2018-05-02 19:01:27 +08:00
|
|
|
|
2021-01-22 18:53:49 +08:00
|
|
|
len = xdp->data_end - xdp->data;
|
2020-08-28 16:26:16 +08:00
|
|
|
if (len > xsk_pool_get_rx_frame_size(xs->pool)) {
|
2020-05-21 03:20:53 +08:00
|
|
|
xs->rx_dropped++;
|
|
|
|
return -ENOSPC;
|
|
|
|
}
|
|
|
|
|
2020-08-28 16:26:16 +08:00
|
|
|
xsk_xdp = xsk_buff_alloc(xs->pool);
|
2020-05-21 03:20:53 +08:00
|
|
|
if (!xsk_xdp) {
|
2018-06-04 20:05:55 +08:00
|
|
|
xs->rx_dropped++;
|
2020-05-21 03:20:53 +08:00
|
|
|
return -ENOSPC;
|
|
|
|
}
|
2018-05-02 19:01:27 +08:00
|
|
|
|
2020-05-21 03:20:53 +08:00
|
|
|
xsk_copy_xdp(xsk_xdp, xdp, len);
|
|
|
|
err = __xsk_rcv_zc(xs, xsk_xdp, len);
|
|
|
|
if (err) {
|
|
|
|
xsk_buff_free(xsk_xdp);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
return 0;
|
2018-05-02 19:01:27 +08:00
|
|
|
}
|
|
|
|
|
2020-12-01 21:56:58 +08:00
|
|
|
static bool xsk_tx_writeable(struct xdp_sock *xs)
|
|
|
|
{
|
|
|
|
if (xskq_cons_present_entries(xs->tx) > xs->tx->nentries / 2)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
xsk: use state member for socket synchronization
Prior the state variable was introduced by Ilya, the dev member was
used to determine whether the socket was bound or not. However, when
dev was read, proper SMP barriers and READ_ONCE were missing. In order
to address the missing barriers and READ_ONCE, we start using the
state variable as a point of synchronization. The state member
read/write is paired with proper SMP barriers, and from this follows
that the members described above does not need READ_ONCE if used in
conjunction with state check.
In all syscalls and the xsk_rcv path we check if state is
XSK_BOUND. If that is the case we do a SMP read barrier, and this
implies that the dev, umem and all rings are correctly setup. Note
that no READ_ONCE are needed for these variable if used when state is
XSK_BOUND (plus the read barrier).
To summarize: The members struct xdp_sock members dev, queue_id, umem,
fq, cq, tx, rx, and state were read lock-less, with incorrect barriers
and missing {READ, WRITE}_ONCE. Now, umem, fq, cq, tx, rx, and state
are read lock-less. When these members are updated, WRITE_ONCE is
used. When read, READ_ONCE are only used when read outside the control
mutex (e.g. mmap) or, not synchronized with the state member
(XSK_BOUND plus smp_rmb())
Note that dev and queue_id do not need a WRITE_ONCE or READ_ONCE, due
to the introduce state synchronization (XSK_BOUND plus smp_rmb()).
Introducing the state check also fixes a race, found by syzcaller, in
xsk_poll() where umem could be accessed when stale.
Suggested-by: Hillf Danton <hdanton@sina.com>
Reported-by: syzbot+c82697e3043781e08802@syzkaller.appspotmail.com
Fixes: 77cd0d7b3f25 ("xsk: add support for need_wakeup flag in AF_XDP rings")
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-09-04 19:49:12 +08:00
|
|
|
static bool xsk_is_bound(struct xdp_sock *xs)
|
|
|
|
{
|
|
|
|
if (READ_ONCE(xs->state) == XSK_BOUND) {
|
|
|
|
/* Matches smp_wmb() in bind(). */
|
|
|
|
smp_rmb();
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2021-01-22 18:53:49 +08:00
|
|
|
static int xsk_rcv_check(struct xdp_sock *xs, struct xdp_buff *xdp)
|
2018-06-04 20:05:55 +08:00
|
|
|
{
|
xsk: use state member for socket synchronization
Prior the state variable was introduced by Ilya, the dev member was
used to determine whether the socket was bound or not. However, when
dev was read, proper SMP barriers and READ_ONCE were missing. In order
to address the missing barriers and READ_ONCE, we start using the
state variable as a point of synchronization. The state member
read/write is paired with proper SMP barriers, and from this follows
that the members described above does not need READ_ONCE if used in
conjunction with state check.
In all syscalls and the xsk_rcv path we check if state is
XSK_BOUND. If that is the case we do a SMP read barrier, and this
implies that the dev, umem and all rings are correctly setup. Note
that no READ_ONCE are needed for these variable if used when state is
XSK_BOUND (plus the read barrier).
To summarize: The members struct xdp_sock members dev, queue_id, umem,
fq, cq, tx, rx, and state were read lock-less, with incorrect barriers
and missing {READ, WRITE}_ONCE. Now, umem, fq, cq, tx, rx, and state
are read lock-less. When these members are updated, WRITE_ONCE is
used. When read, READ_ONCE are only used when read outside the control
mutex (e.g. mmap) or, not synchronized with the state member
(XSK_BOUND plus smp_rmb())
Note that dev and queue_id do not need a WRITE_ONCE or READ_ONCE, due
to the introduce state synchronization (XSK_BOUND plus smp_rmb()).
Introducing the state check also fixes a race, found by syzcaller, in
xsk_poll() where umem could be accessed when stale.
Suggested-by: Hillf Danton <hdanton@sina.com>
Reported-by: syzbot+c82697e3043781e08802@syzkaller.appspotmail.com
Fixes: 77cd0d7b3f25 ("xsk: add support for need_wakeup flag in AF_XDP rings")
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-09-04 19:49:12 +08:00
|
|
|
if (!xsk_is_bound(xs))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2018-06-04 20:05:55 +08:00
|
|
|
if (xs->dev != xdp->rxq->dev || xs->queue_id != xdp->rxq->queue_index)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2020-12-01 02:52:01 +08:00
|
|
|
sk_mark_napi_id_once_xdp(&xs->sk, xdp);
|
2021-01-22 18:53:49 +08:00
|
|
|
return 0;
|
2018-06-04 20:05:55 +08:00
|
|
|
}
|
|
|
|
|
2019-11-01 19:03:46 +08:00
|
|
|
static void xsk_flush(struct xdp_sock *xs)
|
2018-05-02 19:01:27 +08:00
|
|
|
{
|
2019-12-19 20:39:23 +08:00
|
|
|
xskq_prod_submit(xs->rx);
|
2020-08-28 16:26:18 +08:00
|
|
|
__xskq_cons_release(xs->pool->fq);
|
2020-01-20 17:29:17 +08:00
|
|
|
sock_def_readable(&xs->sk);
|
2018-05-02 19:01:27 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
int xsk_generic_rcv(struct xdp_sock *xs, struct xdp_buff *xdp)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
2019-07-03 20:09:16 +08:00
|
|
|
spin_lock_bh(&xs->rx_lock);
|
2021-01-22 18:53:49 +08:00
|
|
|
err = xsk_rcv_check(xs, xdp);
|
|
|
|
if (!err) {
|
|
|
|
err = __xsk_rcv(xs, xdp);
|
|
|
|
xsk_flush(xs);
|
|
|
|
}
|
2019-07-03 20:09:16 +08:00
|
|
|
spin_unlock_bh(&xs->rx_lock);
|
2018-05-02 19:01:27 +08:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2021-01-22 18:53:49 +08:00
|
|
|
static int xsk_rcv(struct xdp_sock *xs, struct xdp_buff *xdp)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
u32 len;
|
|
|
|
|
|
|
|
err = xsk_rcv_check(xs, xdp);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
if (xdp->rxq->mem.type == MEM_TYPE_XSK_BUFF_POOL) {
|
|
|
|
len = xdp->data_end - xdp->data;
|
|
|
|
return __xsk_rcv_zc(xs, xdp, len);
|
|
|
|
}
|
|
|
|
|
|
|
|
err = __xsk_rcv(xs, xdp);
|
|
|
|
if (!err)
|
|
|
|
xdp_return_buff(xdp);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2019-12-19 14:10:02 +08:00
|
|
|
int __xsk_map_redirect(struct xdp_sock *xs, struct xdp_buff *xdp)
|
2019-11-01 19:03:46 +08:00
|
|
|
{
|
2019-12-19 14:10:02 +08:00
|
|
|
struct list_head *flush_list = this_cpu_ptr(&xskmap_flush_list);
|
2019-11-01 19:03:46 +08:00
|
|
|
int err;
|
|
|
|
|
2021-01-22 18:53:49 +08:00
|
|
|
err = xsk_rcv(xs, xdp);
|
2019-11-01 19:03:46 +08:00
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
if (!xs->flush_node.prev)
|
|
|
|
list_add(&xs->flush_node, flush_list);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-12-19 14:10:02 +08:00
|
|
|
void __xsk_map_flush(void)
|
2019-11-01 19:03:46 +08:00
|
|
|
{
|
2019-12-19 14:10:02 +08:00
|
|
|
struct list_head *flush_list = this_cpu_ptr(&xskmap_flush_list);
|
2019-11-01 19:03:46 +08:00
|
|
|
struct xdp_sock *xs, *tmp;
|
|
|
|
|
|
|
|
list_for_each_entry_safe(xs, tmp, flush_list, flush_node) {
|
|
|
|
xsk_flush(xs);
|
|
|
|
__list_del_clearprev(&xs->flush_node);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-08-28 16:26:16 +08:00
|
|
|
void xsk_tx_completed(struct xsk_buff_pool *pool, u32 nb_entries)
|
2018-06-04 20:05:57 +08:00
|
|
|
{
|
2020-08-28 16:26:18 +08:00
|
|
|
xskq_prod_submit_n(pool->cq, nb_entries);
|
2018-06-04 20:05:57 +08:00
|
|
|
}
|
2020-08-28 16:26:16 +08:00
|
|
|
EXPORT_SYMBOL(xsk_tx_completed);
|
2018-06-04 20:05:57 +08:00
|
|
|
|
2020-08-28 16:26:16 +08:00
|
|
|
void xsk_tx_release(struct xsk_buff_pool *pool)
|
2018-06-04 20:05:57 +08:00
|
|
|
{
|
|
|
|
struct xdp_sock *xs;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
2020-08-28 16:26:20 +08:00
|
|
|
list_for_each_entry_rcu(xs, &pool->xsk_tx_list, tx_list) {
|
2020-02-10 23:27:12 +08:00
|
|
|
__xskq_cons_release(xs->tx);
|
2020-12-01 21:56:58 +08:00
|
|
|
if (xsk_tx_writeable(xs))
|
|
|
|
xs->sk.sk_write_space(&xs->sk);
|
2018-06-04 20:05:57 +08:00
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
}
|
2020-08-28 16:26:16 +08:00
|
|
|
EXPORT_SYMBOL(xsk_tx_release);
|
2018-06-04 20:05:57 +08:00
|
|
|
|
2020-08-28 16:26:16 +08:00
|
|
|
bool xsk_tx_peek_desc(struct xsk_buff_pool *pool, struct xdp_desc *desc)
|
2018-06-04 20:05:57 +08:00
|
|
|
{
|
|
|
|
struct xdp_sock *xs;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
2020-08-28 16:26:20 +08:00
|
|
|
list_for_each_entry_rcu(xs, &pool->xsk_tx_list, tx_list) {
|
2020-08-28 16:26:17 +08:00
|
|
|
if (!xskq_cons_peek_desc(xs->tx, desc, pool)) {
|
2020-07-08 15:28:33 +08:00
|
|
|
xs->tx->queue_empty_descs++;
|
2018-06-04 20:05:57 +08:00
|
|
|
continue;
|
2020-07-08 15:28:33 +08:00
|
|
|
}
|
2018-06-04 20:05:57 +08:00
|
|
|
|
2020-04-22 07:29:27 +08:00
|
|
|
/* This is the backpressure mechanism for the Tx path.
|
2019-12-19 20:39:30 +08:00
|
|
|
* Reserve space in the completion queue and only proceed
|
|
|
|
* if there is space in it. This avoids having to implement
|
|
|
|
* any buffering in the Tx path.
|
|
|
|
*/
|
2020-08-28 16:26:18 +08:00
|
|
|
if (xskq_prod_reserve_addr(pool->cq, desc->addr))
|
2018-06-04 20:05:57 +08:00
|
|
|
goto out;
|
|
|
|
|
2019-12-19 20:39:26 +08:00
|
|
|
xskq_cons_release(xs->tx);
|
2018-06-04 20:05:57 +08:00
|
|
|
rcu_read_unlock();
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
out:
|
|
|
|
rcu_read_unlock();
|
|
|
|
return false;
|
|
|
|
}
|
2020-08-28 16:26:16 +08:00
|
|
|
EXPORT_SYMBOL(xsk_tx_peek_desc);
|
2018-06-04 20:05:57 +08:00
|
|
|
|
2022-01-26 00:04:43 +08:00
|
|
|
static u32 xsk_tx_peek_release_fallback(struct xsk_buff_pool *pool, u32 max_entries)
|
2020-11-16 19:12:46 +08:00
|
|
|
{
|
2022-01-26 00:04:43 +08:00
|
|
|
struct xdp_desc *descs = pool->tx_descs;
|
2020-11-16 19:12:46 +08:00
|
|
|
u32 nb_pkts = 0;
|
|
|
|
|
|
|
|
while (nb_pkts < max_entries && xsk_tx_peek_desc(pool, &descs[nb_pkts]))
|
|
|
|
nb_pkts++;
|
|
|
|
|
|
|
|
xsk_tx_release(pool);
|
|
|
|
return nb_pkts;
|
|
|
|
}
|
|
|
|
|
2022-01-26 00:04:43 +08:00
|
|
|
u32 xsk_tx_peek_release_desc_batch(struct xsk_buff_pool *pool, u32 max_entries)
|
2020-11-16 19:12:46 +08:00
|
|
|
{
|
|
|
|
struct xdp_sock *xs;
|
|
|
|
u32 nb_pkts;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
if (!list_is_singular(&pool->xsk_tx_list)) {
|
|
|
|
/* Fallback to the non-batched version */
|
|
|
|
rcu_read_unlock();
|
2022-01-26 00:04:43 +08:00
|
|
|
return xsk_tx_peek_release_fallback(pool, max_entries);
|
2020-11-16 19:12:46 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
xs = list_first_or_null_rcu(&pool->xsk_tx_list, struct xdp_sock, tx_list);
|
|
|
|
if (!xs) {
|
|
|
|
nb_pkts = 0;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2022-01-26 00:04:43 +08:00
|
|
|
nb_pkts = xskq_cons_peek_desc_batch(xs->tx, pool, max_entries);
|
2020-11-16 19:12:46 +08:00
|
|
|
if (!nb_pkts) {
|
|
|
|
xs->tx->queue_empty_descs++;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* This is the backpressure mechanism for the Tx path. Try to
|
|
|
|
* reserve space in the completion queue for all packets, but
|
|
|
|
* if there are fewer slots available, just process that many
|
|
|
|
* packets. This avoids having to implement any buffering in
|
|
|
|
* the Tx path.
|
|
|
|
*/
|
2022-01-26 00:04:43 +08:00
|
|
|
nb_pkts = xskq_prod_reserve_addr_batch(pool->cq, pool->tx_descs, nb_pkts);
|
2020-11-16 19:12:46 +08:00
|
|
|
if (!nb_pkts)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
xskq_cons_release_n(xs->tx, nb_pkts);
|
|
|
|
__xskq_cons_release(xs->tx);
|
|
|
|
xs->sk.sk_write_space(&xs->sk);
|
|
|
|
|
|
|
|
out:
|
|
|
|
rcu_read_unlock();
|
|
|
|
return nb_pkts;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(xsk_tx_peek_release_desc_batch);
|
|
|
|
|
2019-12-18 00:20:42 +08:00
|
|
|
static int xsk_wakeup(struct xdp_sock *xs, u8 flags)
|
2018-06-04 20:05:57 +08:00
|
|
|
{
|
|
|
|
struct net_device *dev = xs->dev;
|
2019-12-18 00:20:42 +08:00
|
|
|
|
xsk: Fix race at socket teardown
Fix a race in the xsk socket teardown code that can lead to a NULL pointer
dereference splat. The current xsk unbind code in xsk_unbind_dev() starts by
setting xs->state to XSK_UNBOUND, sets xs->dev to NULL and then waits for any
NAPI processing to terminate using synchronize_net(). After that, the release
code starts to tear down the socket state and free allocated memory.
BUG: kernel NULL pointer dereference, address: 00000000000000c0
PGD 8000000932469067 P4D 8000000932469067 PUD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Tainted: G I 5.16.0+ #2
Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 03/09/2015
RIP: 0010:__xsk_sendmsg+0x2c/0x690
[...]
RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000040 RCX: ffff8d5fc632d258
RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800
RBP: ffffa2348bd13db0 R08: 0000000000000000 R09: 00007ffffffff000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800
R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000
FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0
Call Trace:
<TASK>
? aa_sk_perm+0x43/0x1b0
xsk_sendmsg+0xf0/0x110
sock_sendmsg+0x65/0x70
__sys_sendto+0x113/0x190
? debug_smp_processor_id+0x17/0x20
? fpregs_assert_state_consistent+0x23/0x50
? exit_to_user_mode_prepare+0xa5/0x1d0
__x64_sys_sendto+0x29/0x30
do_syscall_64+0x3b/0xc0
entry_SYSCALL_64_after_hwframe+0x44/0xae
There are two problems with the current code. First, setting xs->dev to NULL
before waiting for all users to stop using the socket is not correct. The
entry to the data plane functions xsk_poll(), xsk_sendmsg(), and xsk_recvmsg()
are all guarded by a test that xs->state is in the state XSK_BOUND and if not,
it returns right away. But one process might have passed this test but still
have not gotten to the point in which it uses xs->dev in the code. In this
interim, a second process executing xsk_unbind_dev() might have set xs->dev to
NULL which will lead to a crash for the first process. The solution here is
just to get rid of this NULL assignment since it is not used anymore. Before
commit 42fddcc7c64b ("xsk: use state member for socket synchronization"),
xs->dev was the gatekeeper to admit processes into the data plane functions,
but it was replaced with the state variable xs->state in the aforementioned
commit.
The second problem is that synchronize_net() does not wait for any process in
xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() to complete, which means that the
state they rely on might be cleaned up prematurely. This can happen when the
notifier gets called (at driver unload for example) as it uses xsk_unbind_dev().
Solve this by extending the RCU critical region from just the ndo_xsk_wakeup
to the whole functions mentioned above, so that both the test of xs->state ==
XSK_BOUND and the last use of any member of xs is covered by the RCU critical
section. This will guarantee that when synchronize_net() completes, there will
be no processes left executing xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() and
state can be cleaned up safely. Note that we need to drop the RCU lock for the
skb xmit path as it uses functions that might sleep. Due to this, we have to
retest the xs->state after we grab the mutex that protects the skb xmit code
from, among a number of things, an xsk_unbind_dev() being executed from the
notifier at the same time.
Fixes: 42fddcc7c64b ("xsk: use state member for socket synchronization")
Reported-by: Elza Mathew <elza.mathew@intel.com>
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Björn Töpel <bjorn@kernel.org>
Link: https://lore.kernel.org/bpf/20220228094552.10134-1-magnus.karlsson@gmail.com
2022-02-28 17:45:52 +08:00
|
|
|
return dev->netdev_ops->ndo_xsk_wakeup(dev, xs->queue_id, flags);
|
2018-06-04 20:05:57 +08:00
|
|
|
}
|
|
|
|
|
2018-05-02 19:01:34 +08:00
|
|
|
static void xsk_destruct_skb(struct sk_buff *skb)
|
|
|
|
{
|
xsk: new descriptor addressing scheme
Currently, AF_XDP only supports a fixed frame-size memory scheme where
each frame is referenced via an index (idx). A user passes the frame
index to the kernel, and the kernel acts upon the data. Some NICs,
however, do not have a fixed frame-size model, instead they have a
model where a memory window is passed to the hardware and multiple
frames are filled into that window (referred to as the "type-writer"
model).
By changing the descriptor format from the current frame index
addressing scheme, AF_XDP can in the future be extended to support
these kinds of NICs.
In the index-based model, an idx refers to a frame of size
frame_size. Addressing a frame in the UMEM is done by offseting the
UMEM starting address by a global offset, idx * frame_size + offset.
Communicating via the fill- and completion-rings are done by means of
idx.
In this commit, the idx is removed in favor of an address (addr),
which is a relative address ranging over the UMEM. To convert an
idx-based address to the new addr is simply: addr = idx * frame_size +
offset.
We also stop referring to the UMEM "frame" as a frame. Instead it is
simply called a chunk.
To transfer ownership of a chunk to the kernel, the addr of the chunk
is passed in the fill-ring. Note, that the kernel will mask addr to
make it chunk aligned, so there is no need for userspace to do
that. E.g., for a chunk size of 2k, passing an addr of 2048, 2050 or
3000 to the fill-ring will refer to the same chunk.
On the completion-ring, the addr will match that of the Tx descriptor,
passed to the kernel.
Changing the descriptor format to use chunks/addr will allow for
future changes to move to a type-writer based model, where multiple
frames can reside in one chunk. In this model passing one single chunk
into the fill-ring, would potentially result in multiple Rx
descriptors.
This commit changes the uapi of AF_XDP sockets, and updates the
documentation.
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-06-04 19:57:13 +08:00
|
|
|
u64 addr = (u64)(long)skb_shinfo(skb)->destructor_arg;
|
2018-05-02 19:01:34 +08:00
|
|
|
struct xdp_sock *xs = xdp_sk(skb->sk);
|
2018-06-29 15:48:20 +08:00
|
|
|
unsigned long flags;
|
2018-05-02 19:01:34 +08:00
|
|
|
|
2020-12-18 21:45:24 +08:00
|
|
|
spin_lock_irqsave(&xs->pool->cq_lock, flags);
|
2020-08-28 16:26:18 +08:00
|
|
|
xskq_prod_submit_addr(xs->pool->cq, addr);
|
2020-12-18 21:45:24 +08:00
|
|
|
spin_unlock_irqrestore(&xs->pool->cq_lock, flags);
|
2018-05-02 19:01:34 +08:00
|
|
|
|
|
|
|
sock_wfree(skb);
|
|
|
|
}
|
|
|
|
|
2021-02-19 04:50:45 +08:00
|
|
|
static struct sk_buff *xsk_build_skb_zerocopy(struct xdp_sock *xs,
|
|
|
|
struct xdp_desc *desc)
|
|
|
|
{
|
|
|
|
struct xsk_buff_pool *pool = xs->pool;
|
|
|
|
u32 hr, len, ts, offset, copy, copied;
|
|
|
|
struct sk_buff *skb;
|
|
|
|
struct page *page;
|
|
|
|
void *buffer;
|
|
|
|
int err, i;
|
|
|
|
u64 addr;
|
|
|
|
|
|
|
|
hr = max(NET_SKB_PAD, L1_CACHE_ALIGN(xs->dev->needed_headroom));
|
|
|
|
|
|
|
|
skb = sock_alloc_send_skb(&xs->sk, hr, 1, &err);
|
|
|
|
if (unlikely(!skb))
|
|
|
|
return ERR_PTR(err);
|
|
|
|
|
|
|
|
skb_reserve(skb, hr);
|
|
|
|
|
|
|
|
addr = desc->addr;
|
|
|
|
len = desc->len;
|
|
|
|
ts = pool->unaligned ? len : pool->chunk_size;
|
|
|
|
|
|
|
|
buffer = xsk_buff_raw_get_data(pool, addr);
|
|
|
|
offset = offset_in_page(buffer);
|
|
|
|
addr = buffer - pool->addrs;
|
|
|
|
|
|
|
|
for (copied = 0, i = 0; copied < len; i++) {
|
|
|
|
page = pool->umem->pgs[addr >> PAGE_SHIFT];
|
|
|
|
get_page(page);
|
|
|
|
|
|
|
|
copy = min_t(u32, PAGE_SIZE - offset, len - copied);
|
|
|
|
skb_fill_page_desc(skb, i, page, offset, copy);
|
|
|
|
|
|
|
|
copied += copy;
|
|
|
|
addr += copy;
|
|
|
|
offset = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
skb->len += len;
|
|
|
|
skb->data_len += len;
|
|
|
|
skb->truesize += ts;
|
|
|
|
|
|
|
|
refcount_add(ts, &xs->sk.sk_wmem_alloc);
|
|
|
|
|
|
|
|
return skb;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct sk_buff *xsk_build_skb(struct xdp_sock *xs,
|
|
|
|
struct xdp_desc *desc)
|
|
|
|
{
|
|
|
|
struct net_device *dev = xs->dev;
|
|
|
|
struct sk_buff *skb;
|
|
|
|
|
|
|
|
if (dev->priv_flags & IFF_TX_SKB_NO_LINEAR) {
|
|
|
|
skb = xsk_build_skb_zerocopy(xs, desc);
|
|
|
|
if (IS_ERR(skb))
|
|
|
|
return skb;
|
|
|
|
} else {
|
|
|
|
u32 hr, tr, len;
|
|
|
|
void *buffer;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
hr = max(NET_SKB_PAD, L1_CACHE_ALIGN(dev->needed_headroom));
|
|
|
|
tr = dev->needed_tailroom;
|
|
|
|
len = desc->len;
|
|
|
|
|
|
|
|
skb = sock_alloc_send_skb(&xs->sk, hr + len + tr, 1, &err);
|
|
|
|
if (unlikely(!skb))
|
|
|
|
return ERR_PTR(err);
|
|
|
|
|
|
|
|
skb_reserve(skb, hr);
|
|
|
|
skb_put(skb, len);
|
|
|
|
|
|
|
|
buffer = xsk_buff_raw_get_data(xs->pool, desc->addr);
|
|
|
|
err = skb_store_bits(skb, 0, buffer, len);
|
|
|
|
if (unlikely(err)) {
|
|
|
|
kfree_skb(skb);
|
|
|
|
return ERR_PTR(err);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
skb->dev = dev;
|
|
|
|
skb->priority = xs->sk.sk_priority;
|
|
|
|
skb->mark = xs->sk.sk_mark;
|
|
|
|
skb_shinfo(skb)->destructor_arg = (void *)(long)desc->addr;
|
|
|
|
skb->destructor = xsk_destruct_skb;
|
|
|
|
|
|
|
|
return skb;
|
|
|
|
}
|
|
|
|
|
2019-10-02 14:31:59 +08:00
|
|
|
static int xsk_generic_xmit(struct sock *sk)
|
2018-05-02 19:01:34 +08:00
|
|
|
{
|
|
|
|
struct xdp_sock *xs = xdp_sk(sk);
|
2019-10-02 14:31:59 +08:00
|
|
|
u32 max_batch = TX_BATCH_SIZE;
|
2018-05-02 19:01:34 +08:00
|
|
|
bool sent_frame = false;
|
|
|
|
struct xdp_desc desc;
|
|
|
|
struct sk_buff *skb;
|
2020-12-18 21:45:24 +08:00
|
|
|
unsigned long flags;
|
2018-05-02 19:01:34 +08:00
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
mutex_lock(&xs->mutex);
|
|
|
|
|
xsk: Fix race at socket teardown
Fix a race in the xsk socket teardown code that can lead to a NULL pointer
dereference splat. The current xsk unbind code in xsk_unbind_dev() starts by
setting xs->state to XSK_UNBOUND, sets xs->dev to NULL and then waits for any
NAPI processing to terminate using synchronize_net(). After that, the release
code starts to tear down the socket state and free allocated memory.
BUG: kernel NULL pointer dereference, address: 00000000000000c0
PGD 8000000932469067 P4D 8000000932469067 PUD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Tainted: G I 5.16.0+ #2
Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 03/09/2015
RIP: 0010:__xsk_sendmsg+0x2c/0x690
[...]
RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000040 RCX: ffff8d5fc632d258
RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800
RBP: ffffa2348bd13db0 R08: 0000000000000000 R09: 00007ffffffff000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800
R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000
FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0
Call Trace:
<TASK>
? aa_sk_perm+0x43/0x1b0
xsk_sendmsg+0xf0/0x110
sock_sendmsg+0x65/0x70
__sys_sendto+0x113/0x190
? debug_smp_processor_id+0x17/0x20
? fpregs_assert_state_consistent+0x23/0x50
? exit_to_user_mode_prepare+0xa5/0x1d0
__x64_sys_sendto+0x29/0x30
do_syscall_64+0x3b/0xc0
entry_SYSCALL_64_after_hwframe+0x44/0xae
There are two problems with the current code. First, setting xs->dev to NULL
before waiting for all users to stop using the socket is not correct. The
entry to the data plane functions xsk_poll(), xsk_sendmsg(), and xsk_recvmsg()
are all guarded by a test that xs->state is in the state XSK_BOUND and if not,
it returns right away. But one process might have passed this test but still
have not gotten to the point in which it uses xs->dev in the code. In this
interim, a second process executing xsk_unbind_dev() might have set xs->dev to
NULL which will lead to a crash for the first process. The solution here is
just to get rid of this NULL assignment since it is not used anymore. Before
commit 42fddcc7c64b ("xsk: use state member for socket synchronization"),
xs->dev was the gatekeeper to admit processes into the data plane functions,
but it was replaced with the state variable xs->state in the aforementioned
commit.
The second problem is that synchronize_net() does not wait for any process in
xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() to complete, which means that the
state they rely on might be cleaned up prematurely. This can happen when the
notifier gets called (at driver unload for example) as it uses xsk_unbind_dev().
Solve this by extending the RCU critical region from just the ndo_xsk_wakeup
to the whole functions mentioned above, so that both the test of xs->state ==
XSK_BOUND and the last use of any member of xs is covered by the RCU critical
section. This will guarantee that when synchronize_net() completes, there will
be no processes left executing xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() and
state can be cleaned up safely. Note that we need to drop the RCU lock for the
skb xmit path as it uses functions that might sleep. Due to this, we have to
retest the xs->state after we grab the mutex that protects the skb xmit code
from, among a number of things, an xsk_unbind_dev() being executed from the
notifier at the same time.
Fixes: 42fddcc7c64b ("xsk: use state member for socket synchronization")
Reported-by: Elza Mathew <elza.mathew@intel.com>
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Björn Töpel <bjorn@kernel.org>
Link: https://lore.kernel.org/bpf/20220228094552.10134-1-magnus.karlsson@gmail.com
2022-02-28 17:45:52 +08:00
|
|
|
/* Since we dropped the RCU read lock, the socket state might have changed. */
|
|
|
|
if (unlikely(!xsk_is_bound(xs))) {
|
|
|
|
err = -ENXIO;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2019-07-04 22:25:03 +08:00
|
|
|
if (xs->queue_id >= xs->dev->real_num_tx_queues)
|
|
|
|
goto out;
|
|
|
|
|
2020-08-28 16:26:17 +08:00
|
|
|
while (xskq_cons_peek_desc(xs->tx, &desc, xs->pool)) {
|
2018-05-02 19:01:34 +08:00
|
|
|
if (max_batch-- == 0) {
|
|
|
|
err = -EAGAIN;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2021-02-19 04:50:45 +08:00
|
|
|
skb = xsk_build_skb(xs, &desc);
|
|
|
|
if (IS_ERR(skb)) {
|
|
|
|
err = PTR_ERR(skb);
|
2018-05-02 19:01:34 +08:00
|
|
|
goto out;
|
2021-02-19 04:50:45 +08:00
|
|
|
}
|
2018-05-02 19:01:34 +08:00
|
|
|
|
2020-04-22 07:29:27 +08:00
|
|
|
/* This is the backpressure mechanism for the Tx path.
|
2019-12-19 20:39:30 +08:00
|
|
|
* Reserve space in the completion queue and only proceed
|
|
|
|
* if there is space in it. This avoids having to implement
|
|
|
|
* any buffering in the Tx path.
|
|
|
|
*/
|
2020-12-18 21:45:24 +08:00
|
|
|
spin_lock_irqsave(&xs->pool->cq_lock, flags);
|
2021-02-19 04:50:45 +08:00
|
|
|
if (xskq_prod_reserve(xs->pool->cq)) {
|
2020-12-18 21:45:24 +08:00
|
|
|
spin_unlock_irqrestore(&xs->pool->cq_lock, flags);
|
2018-05-02 19:01:34 +08:00
|
|
|
kfree_skb(skb);
|
|
|
|
goto out;
|
|
|
|
}
|
2020-12-18 21:45:24 +08:00
|
|
|
spin_unlock_irqrestore(&xs->pool->cq_lock, flags);
|
2018-05-02 19:01:34 +08:00
|
|
|
|
2020-11-24 01:56:00 +08:00
|
|
|
err = __dev_direct_xmit(skb, xs->queue_id);
|
2020-09-16 20:00:25 +08:00
|
|
|
if (err == NETDEV_TX_BUSY) {
|
|
|
|
/* Tell user-space to retry the send */
|
|
|
|
skb->destructor = sock_wfree;
|
2020-12-18 21:45:25 +08:00
|
|
|
spin_lock_irqsave(&xs->pool->cq_lock, flags);
|
|
|
|
xskq_prod_cancel(xs->pool->cq);
|
|
|
|
spin_unlock_irqrestore(&xs->pool->cq_lock, flags);
|
2020-09-16 20:00:25 +08:00
|
|
|
/* Free skb without triggering the perf drop trace */
|
|
|
|
consume_skb(skb);
|
|
|
|
err = -EAGAIN;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2019-12-19 20:39:26 +08:00
|
|
|
xskq_cons_release(xs->tx);
|
2018-05-02 19:01:34 +08:00
|
|
|
/* Ignore NET_XMIT_CN as packet might have been sent */
|
2020-09-16 20:00:25 +08:00
|
|
|
if (err == NET_XMIT_DROP) {
|
2018-06-29 15:48:18 +08:00
|
|
|
/* SKB completed but not sent */
|
|
|
|
err = -EBUSY;
|
2018-05-02 19:01:34 +08:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
sent_frame = true;
|
|
|
|
}
|
|
|
|
|
2020-07-08 15:28:33 +08:00
|
|
|
xs->tx->queue_empty_descs++;
|
|
|
|
|
2018-05-02 19:01:34 +08:00
|
|
|
out:
|
|
|
|
if (sent_frame)
|
2020-12-01 21:56:58 +08:00
|
|
|
if (xsk_tx_writeable(xs))
|
|
|
|
sk->sk_write_space(sk);
|
2018-05-02 19:01:34 +08:00
|
|
|
|
|
|
|
mutex_unlock(&xs->mutex);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
xsk: Fix race at socket teardown
Fix a race in the xsk socket teardown code that can lead to a NULL pointer
dereference splat. The current xsk unbind code in xsk_unbind_dev() starts by
setting xs->state to XSK_UNBOUND, sets xs->dev to NULL and then waits for any
NAPI processing to terminate using synchronize_net(). After that, the release
code starts to tear down the socket state and free allocated memory.
BUG: kernel NULL pointer dereference, address: 00000000000000c0
PGD 8000000932469067 P4D 8000000932469067 PUD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Tainted: G I 5.16.0+ #2
Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 03/09/2015
RIP: 0010:__xsk_sendmsg+0x2c/0x690
[...]
RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000040 RCX: ffff8d5fc632d258
RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800
RBP: ffffa2348bd13db0 R08: 0000000000000000 R09: 00007ffffffff000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800
R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000
FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0
Call Trace:
<TASK>
? aa_sk_perm+0x43/0x1b0
xsk_sendmsg+0xf0/0x110
sock_sendmsg+0x65/0x70
__sys_sendto+0x113/0x190
? debug_smp_processor_id+0x17/0x20
? fpregs_assert_state_consistent+0x23/0x50
? exit_to_user_mode_prepare+0xa5/0x1d0
__x64_sys_sendto+0x29/0x30
do_syscall_64+0x3b/0xc0
entry_SYSCALL_64_after_hwframe+0x44/0xae
There are two problems with the current code. First, setting xs->dev to NULL
before waiting for all users to stop using the socket is not correct. The
entry to the data plane functions xsk_poll(), xsk_sendmsg(), and xsk_recvmsg()
are all guarded by a test that xs->state is in the state XSK_BOUND and if not,
it returns right away. But one process might have passed this test but still
have not gotten to the point in which it uses xs->dev in the code. In this
interim, a second process executing xsk_unbind_dev() might have set xs->dev to
NULL which will lead to a crash for the first process. The solution here is
just to get rid of this NULL assignment since it is not used anymore. Before
commit 42fddcc7c64b ("xsk: use state member for socket synchronization"),
xs->dev was the gatekeeper to admit processes into the data plane functions,
but it was replaced with the state variable xs->state in the aforementioned
commit.
The second problem is that synchronize_net() does not wait for any process in
xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() to complete, which means that the
state they rely on might be cleaned up prematurely. This can happen when the
notifier gets called (at driver unload for example) as it uses xsk_unbind_dev().
Solve this by extending the RCU critical region from just the ndo_xsk_wakeup
to the whole functions mentioned above, so that both the test of xs->state ==
XSK_BOUND and the last use of any member of xs is covered by the RCU critical
section. This will guarantee that when synchronize_net() completes, there will
be no processes left executing xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() and
state can be cleaned up safely. Note that we need to drop the RCU lock for the
skb xmit path as it uses functions that might sleep. Due to this, we have to
retest the xs->state after we grab the mutex that protects the skb xmit code
from, among a number of things, an xsk_unbind_dev() being executed from the
notifier at the same time.
Fixes: 42fddcc7c64b ("xsk: use state member for socket synchronization")
Reported-by: Elza Mathew <elza.mathew@intel.com>
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Björn Töpel <bjorn@kernel.org>
Link: https://lore.kernel.org/bpf/20220228094552.10134-1-magnus.karlsson@gmail.com
2022-02-28 17:45:52 +08:00
|
|
|
static int xsk_xmit(struct sock *sk)
|
2019-10-02 14:31:59 +08:00
|
|
|
{
|
|
|
|
struct xdp_sock *xs = xdp_sk(sk);
|
xsk: Fix race at socket teardown
Fix a race in the xsk socket teardown code that can lead to a NULL pointer
dereference splat. The current xsk unbind code in xsk_unbind_dev() starts by
setting xs->state to XSK_UNBOUND, sets xs->dev to NULL and then waits for any
NAPI processing to terminate using synchronize_net(). After that, the release
code starts to tear down the socket state and free allocated memory.
BUG: kernel NULL pointer dereference, address: 00000000000000c0
PGD 8000000932469067 P4D 8000000932469067 PUD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Tainted: G I 5.16.0+ #2
Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 03/09/2015
RIP: 0010:__xsk_sendmsg+0x2c/0x690
[...]
RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000040 RCX: ffff8d5fc632d258
RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800
RBP: ffffa2348bd13db0 R08: 0000000000000000 R09: 00007ffffffff000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800
R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000
FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0
Call Trace:
<TASK>
? aa_sk_perm+0x43/0x1b0
xsk_sendmsg+0xf0/0x110
sock_sendmsg+0x65/0x70
__sys_sendto+0x113/0x190
? debug_smp_processor_id+0x17/0x20
? fpregs_assert_state_consistent+0x23/0x50
? exit_to_user_mode_prepare+0xa5/0x1d0
__x64_sys_sendto+0x29/0x30
do_syscall_64+0x3b/0xc0
entry_SYSCALL_64_after_hwframe+0x44/0xae
There are two problems with the current code. First, setting xs->dev to NULL
before waiting for all users to stop using the socket is not correct. The
entry to the data plane functions xsk_poll(), xsk_sendmsg(), and xsk_recvmsg()
are all guarded by a test that xs->state is in the state XSK_BOUND and if not,
it returns right away. But one process might have passed this test but still
have not gotten to the point in which it uses xs->dev in the code. In this
interim, a second process executing xsk_unbind_dev() might have set xs->dev to
NULL which will lead to a crash for the first process. The solution here is
just to get rid of this NULL assignment since it is not used anymore. Before
commit 42fddcc7c64b ("xsk: use state member for socket synchronization"),
xs->dev was the gatekeeper to admit processes into the data plane functions,
but it was replaced with the state variable xs->state in the aforementioned
commit.
The second problem is that synchronize_net() does not wait for any process in
xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() to complete, which means that the
state they rely on might be cleaned up prematurely. This can happen when the
notifier gets called (at driver unload for example) as it uses xsk_unbind_dev().
Solve this by extending the RCU critical region from just the ndo_xsk_wakeup
to the whole functions mentioned above, so that both the test of xs->state ==
XSK_BOUND and the last use of any member of xs is covered by the RCU critical
section. This will guarantee that when synchronize_net() completes, there will
be no processes left executing xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() and
state can be cleaned up safely. Note that we need to drop the RCU lock for the
skb xmit path as it uses functions that might sleep. Due to this, we have to
retest the xs->state after we grab the mutex that protects the skb xmit code
from, among a number of things, an xsk_unbind_dev() being executed from the
notifier at the same time.
Fixes: 42fddcc7c64b ("xsk: use state member for socket synchronization")
Reported-by: Elza Mathew <elza.mathew@intel.com>
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Björn Töpel <bjorn@kernel.org>
Link: https://lore.kernel.org/bpf/20220228094552.10134-1-magnus.karlsson@gmail.com
2022-02-28 17:45:52 +08:00
|
|
|
int ret;
|
2019-10-02 14:31:59 +08:00
|
|
|
|
|
|
|
if (unlikely(!(xs->dev->flags & IFF_UP)))
|
|
|
|
return -ENETDOWN;
|
|
|
|
if (unlikely(!xs->tx))
|
|
|
|
return -ENOBUFS;
|
|
|
|
|
xsk: Fix race at socket teardown
Fix a race in the xsk socket teardown code that can lead to a NULL pointer
dereference splat. The current xsk unbind code in xsk_unbind_dev() starts by
setting xs->state to XSK_UNBOUND, sets xs->dev to NULL and then waits for any
NAPI processing to terminate using synchronize_net(). After that, the release
code starts to tear down the socket state and free allocated memory.
BUG: kernel NULL pointer dereference, address: 00000000000000c0
PGD 8000000932469067 P4D 8000000932469067 PUD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Tainted: G I 5.16.0+ #2
Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 03/09/2015
RIP: 0010:__xsk_sendmsg+0x2c/0x690
[...]
RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000040 RCX: ffff8d5fc632d258
RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800
RBP: ffffa2348bd13db0 R08: 0000000000000000 R09: 00007ffffffff000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800
R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000
FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0
Call Trace:
<TASK>
? aa_sk_perm+0x43/0x1b0
xsk_sendmsg+0xf0/0x110
sock_sendmsg+0x65/0x70
__sys_sendto+0x113/0x190
? debug_smp_processor_id+0x17/0x20
? fpregs_assert_state_consistent+0x23/0x50
? exit_to_user_mode_prepare+0xa5/0x1d0
__x64_sys_sendto+0x29/0x30
do_syscall_64+0x3b/0xc0
entry_SYSCALL_64_after_hwframe+0x44/0xae
There are two problems with the current code. First, setting xs->dev to NULL
before waiting for all users to stop using the socket is not correct. The
entry to the data plane functions xsk_poll(), xsk_sendmsg(), and xsk_recvmsg()
are all guarded by a test that xs->state is in the state XSK_BOUND and if not,
it returns right away. But one process might have passed this test but still
have not gotten to the point in which it uses xs->dev in the code. In this
interim, a second process executing xsk_unbind_dev() might have set xs->dev to
NULL which will lead to a crash for the first process. The solution here is
just to get rid of this NULL assignment since it is not used anymore. Before
commit 42fddcc7c64b ("xsk: use state member for socket synchronization"),
xs->dev was the gatekeeper to admit processes into the data plane functions,
but it was replaced with the state variable xs->state in the aforementioned
commit.
The second problem is that synchronize_net() does not wait for any process in
xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() to complete, which means that the
state they rely on might be cleaned up prematurely. This can happen when the
notifier gets called (at driver unload for example) as it uses xsk_unbind_dev().
Solve this by extending the RCU critical region from just the ndo_xsk_wakeup
to the whole functions mentioned above, so that both the test of xs->state ==
XSK_BOUND and the last use of any member of xs is covered by the RCU critical
section. This will guarantee that when synchronize_net() completes, there will
be no processes left executing xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() and
state can be cleaned up safely. Note that we need to drop the RCU lock for the
skb xmit path as it uses functions that might sleep. Due to this, we have to
retest the xs->state after we grab the mutex that protects the skb xmit code
from, among a number of things, an xsk_unbind_dev() being executed from the
notifier at the same time.
Fixes: 42fddcc7c64b ("xsk: use state member for socket synchronization")
Reported-by: Elza Mathew <elza.mathew@intel.com>
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Björn Töpel <bjorn@kernel.org>
Link: https://lore.kernel.org/bpf/20220228094552.10134-1-magnus.karlsson@gmail.com
2022-02-28 17:45:52 +08:00
|
|
|
if (xs->zc)
|
|
|
|
return xsk_wakeup(xs, XDP_WAKEUP_TX);
|
|
|
|
|
|
|
|
/* Drop the RCU lock since the SKB path might sleep. */
|
|
|
|
rcu_read_unlock();
|
|
|
|
ret = xsk_generic_xmit(sk);
|
|
|
|
/* Reaquire RCU lock before going into common code. */
|
|
|
|
rcu_read_lock();
|
|
|
|
|
|
|
|
return ret;
|
2019-10-02 14:31:59 +08:00
|
|
|
}
|
|
|
|
|
2020-12-01 02:52:00 +08:00
|
|
|
static bool xsk_no_wakeup(struct sock *sk)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_NET_RX_BUSY_POLL
|
|
|
|
/* Prefer busy-polling, skip the wakeup. */
|
|
|
|
return READ_ONCE(sk->sk_prefer_busy_poll) && READ_ONCE(sk->sk_ll_usec) &&
|
|
|
|
READ_ONCE(sk->sk_napi_id) >= MIN_NAPI_ID;
|
|
|
|
#else
|
|
|
|
return false;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
xsk: Fix race at socket teardown
Fix a race in the xsk socket teardown code that can lead to a NULL pointer
dereference splat. The current xsk unbind code in xsk_unbind_dev() starts by
setting xs->state to XSK_UNBOUND, sets xs->dev to NULL and then waits for any
NAPI processing to terminate using synchronize_net(). After that, the release
code starts to tear down the socket state and free allocated memory.
BUG: kernel NULL pointer dereference, address: 00000000000000c0
PGD 8000000932469067 P4D 8000000932469067 PUD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Tainted: G I 5.16.0+ #2
Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 03/09/2015
RIP: 0010:__xsk_sendmsg+0x2c/0x690
[...]
RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000040 RCX: ffff8d5fc632d258
RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800
RBP: ffffa2348bd13db0 R08: 0000000000000000 R09: 00007ffffffff000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800
R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000
FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0
Call Trace:
<TASK>
? aa_sk_perm+0x43/0x1b0
xsk_sendmsg+0xf0/0x110
sock_sendmsg+0x65/0x70
__sys_sendto+0x113/0x190
? debug_smp_processor_id+0x17/0x20
? fpregs_assert_state_consistent+0x23/0x50
? exit_to_user_mode_prepare+0xa5/0x1d0
__x64_sys_sendto+0x29/0x30
do_syscall_64+0x3b/0xc0
entry_SYSCALL_64_after_hwframe+0x44/0xae
There are two problems with the current code. First, setting xs->dev to NULL
before waiting for all users to stop using the socket is not correct. The
entry to the data plane functions xsk_poll(), xsk_sendmsg(), and xsk_recvmsg()
are all guarded by a test that xs->state is in the state XSK_BOUND and if not,
it returns right away. But one process might have passed this test but still
have not gotten to the point in which it uses xs->dev in the code. In this
interim, a second process executing xsk_unbind_dev() might have set xs->dev to
NULL which will lead to a crash for the first process. The solution here is
just to get rid of this NULL assignment since it is not used anymore. Before
commit 42fddcc7c64b ("xsk: use state member for socket synchronization"),
xs->dev was the gatekeeper to admit processes into the data plane functions,
but it was replaced with the state variable xs->state in the aforementioned
commit.
The second problem is that synchronize_net() does not wait for any process in
xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() to complete, which means that the
state they rely on might be cleaned up prematurely. This can happen when the
notifier gets called (at driver unload for example) as it uses xsk_unbind_dev().
Solve this by extending the RCU critical region from just the ndo_xsk_wakeup
to the whole functions mentioned above, so that both the test of xs->state ==
XSK_BOUND and the last use of any member of xs is covered by the RCU critical
section. This will guarantee that when synchronize_net() completes, there will
be no processes left executing xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() and
state can be cleaned up safely. Note that we need to drop the RCU lock for the
skb xmit path as it uses functions that might sleep. Due to this, we have to
retest the xs->state after we grab the mutex that protects the skb xmit code
from, among a number of things, an xsk_unbind_dev() being executed from the
notifier at the same time.
Fixes: 42fddcc7c64b ("xsk: use state member for socket synchronization")
Reported-by: Elza Mathew <elza.mathew@intel.com>
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Björn Töpel <bjorn@kernel.org>
Link: https://lore.kernel.org/bpf/20220228094552.10134-1-magnus.karlsson@gmail.com
2022-02-28 17:45:52 +08:00
|
|
|
static int __xsk_sendmsg(struct socket *sock, struct msghdr *m, size_t total_len)
|
2018-05-02 19:01:34 +08:00
|
|
|
{
|
2018-06-04 20:05:57 +08:00
|
|
|
bool need_wait = !(m->msg_flags & MSG_DONTWAIT);
|
2018-05-02 19:01:34 +08:00
|
|
|
struct sock *sk = sock->sk;
|
|
|
|
struct xdp_sock *xs = xdp_sk(sk);
|
2020-12-01 02:51:59 +08:00
|
|
|
struct xsk_buff_pool *pool;
|
2018-05-02 19:01:34 +08:00
|
|
|
|
xsk: use state member for socket synchronization
Prior the state variable was introduced by Ilya, the dev member was
used to determine whether the socket was bound or not. However, when
dev was read, proper SMP barriers and READ_ONCE were missing. In order
to address the missing barriers and READ_ONCE, we start using the
state variable as a point of synchronization. The state member
read/write is paired with proper SMP barriers, and from this follows
that the members described above does not need READ_ONCE if used in
conjunction with state check.
In all syscalls and the xsk_rcv path we check if state is
XSK_BOUND. If that is the case we do a SMP read barrier, and this
implies that the dev, umem and all rings are correctly setup. Note
that no READ_ONCE are needed for these variable if used when state is
XSK_BOUND (plus the read barrier).
To summarize: The members struct xdp_sock members dev, queue_id, umem,
fq, cq, tx, rx, and state were read lock-less, with incorrect barriers
and missing {READ, WRITE}_ONCE. Now, umem, fq, cq, tx, rx, and state
are read lock-less. When these members are updated, WRITE_ONCE is
used. When read, READ_ONCE are only used when read outside the control
mutex (e.g. mmap) or, not synchronized with the state member
(XSK_BOUND plus smp_rmb())
Note that dev and queue_id do not need a WRITE_ONCE or READ_ONCE, due
to the introduce state synchronization (XSK_BOUND plus smp_rmb()).
Introducing the state check also fixes a race, found by syzcaller, in
xsk_poll() where umem could be accessed when stale.
Suggested-by: Hillf Danton <hdanton@sina.com>
Reported-by: syzbot+c82697e3043781e08802@syzkaller.appspotmail.com
Fixes: 77cd0d7b3f25 ("xsk: add support for need_wakeup flag in AF_XDP rings")
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-09-04 19:49:12 +08:00
|
|
|
if (unlikely(!xsk_is_bound(xs)))
|
2018-05-02 19:01:34 +08:00
|
|
|
return -ENXIO;
|
2019-10-02 14:31:59 +08:00
|
|
|
if (unlikely(need_wait))
|
2018-06-04 20:05:57 +08:00
|
|
|
return -EOPNOTSUPP;
|
2018-05-02 19:01:34 +08:00
|
|
|
|
2020-12-01 02:52:00 +08:00
|
|
|
if (sk_can_busy_loop(sk))
|
|
|
|
sk_busy_loop(sk, 1); /* only support non-blocking sockets */
|
|
|
|
|
|
|
|
if (xsk_no_wakeup(sk))
|
|
|
|
return 0;
|
|
|
|
|
2020-12-01 02:51:59 +08:00
|
|
|
pool = xs->pool;
|
|
|
|
if (pool->cached_need_wakeup & XDP_WAKEUP_TX)
|
xsk: Fix race at socket teardown
Fix a race in the xsk socket teardown code that can lead to a NULL pointer
dereference splat. The current xsk unbind code in xsk_unbind_dev() starts by
setting xs->state to XSK_UNBOUND, sets xs->dev to NULL and then waits for any
NAPI processing to terminate using synchronize_net(). After that, the release
code starts to tear down the socket state and free allocated memory.
BUG: kernel NULL pointer dereference, address: 00000000000000c0
PGD 8000000932469067 P4D 8000000932469067 PUD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Tainted: G I 5.16.0+ #2
Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 03/09/2015
RIP: 0010:__xsk_sendmsg+0x2c/0x690
[...]
RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000040 RCX: ffff8d5fc632d258
RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800
RBP: ffffa2348bd13db0 R08: 0000000000000000 R09: 00007ffffffff000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800
R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000
FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0
Call Trace:
<TASK>
? aa_sk_perm+0x43/0x1b0
xsk_sendmsg+0xf0/0x110
sock_sendmsg+0x65/0x70
__sys_sendto+0x113/0x190
? debug_smp_processor_id+0x17/0x20
? fpregs_assert_state_consistent+0x23/0x50
? exit_to_user_mode_prepare+0xa5/0x1d0
__x64_sys_sendto+0x29/0x30
do_syscall_64+0x3b/0xc0
entry_SYSCALL_64_after_hwframe+0x44/0xae
There are two problems with the current code. First, setting xs->dev to NULL
before waiting for all users to stop using the socket is not correct. The
entry to the data plane functions xsk_poll(), xsk_sendmsg(), and xsk_recvmsg()
are all guarded by a test that xs->state is in the state XSK_BOUND and if not,
it returns right away. But one process might have passed this test but still
have not gotten to the point in which it uses xs->dev in the code. In this
interim, a second process executing xsk_unbind_dev() might have set xs->dev to
NULL which will lead to a crash for the first process. The solution here is
just to get rid of this NULL assignment since it is not used anymore. Before
commit 42fddcc7c64b ("xsk: use state member for socket synchronization"),
xs->dev was the gatekeeper to admit processes into the data plane functions,
but it was replaced with the state variable xs->state in the aforementioned
commit.
The second problem is that synchronize_net() does not wait for any process in
xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() to complete, which means that the
state they rely on might be cleaned up prematurely. This can happen when the
notifier gets called (at driver unload for example) as it uses xsk_unbind_dev().
Solve this by extending the RCU critical region from just the ndo_xsk_wakeup
to the whole functions mentioned above, so that both the test of xs->state ==
XSK_BOUND and the last use of any member of xs is covered by the RCU critical
section. This will guarantee that when synchronize_net() completes, there will
be no processes left executing xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() and
state can be cleaned up safely. Note that we need to drop the RCU lock for the
skb xmit path as it uses functions that might sleep. Due to this, we have to
retest the xs->state after we grab the mutex that protects the skb xmit code
from, among a number of things, an xsk_unbind_dev() being executed from the
notifier at the same time.
Fixes: 42fddcc7c64b ("xsk: use state member for socket synchronization")
Reported-by: Elza Mathew <elza.mathew@intel.com>
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Björn Töpel <bjorn@kernel.org>
Link: https://lore.kernel.org/bpf/20220228094552.10134-1-magnus.karlsson@gmail.com
2022-02-28 17:45:52 +08:00
|
|
|
return xsk_xmit(sk);
|
2020-12-01 02:51:59 +08:00
|
|
|
return 0;
|
2018-05-02 19:01:34 +08:00
|
|
|
}
|
|
|
|
|
xsk: Fix race at socket teardown
Fix a race in the xsk socket teardown code that can lead to a NULL pointer
dereference splat. The current xsk unbind code in xsk_unbind_dev() starts by
setting xs->state to XSK_UNBOUND, sets xs->dev to NULL and then waits for any
NAPI processing to terminate using synchronize_net(). After that, the release
code starts to tear down the socket state and free allocated memory.
BUG: kernel NULL pointer dereference, address: 00000000000000c0
PGD 8000000932469067 P4D 8000000932469067 PUD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Tainted: G I 5.16.0+ #2
Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 03/09/2015
RIP: 0010:__xsk_sendmsg+0x2c/0x690
[...]
RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000040 RCX: ffff8d5fc632d258
RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800
RBP: ffffa2348bd13db0 R08: 0000000000000000 R09: 00007ffffffff000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800
R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000
FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0
Call Trace:
<TASK>
? aa_sk_perm+0x43/0x1b0
xsk_sendmsg+0xf0/0x110
sock_sendmsg+0x65/0x70
__sys_sendto+0x113/0x190
? debug_smp_processor_id+0x17/0x20
? fpregs_assert_state_consistent+0x23/0x50
? exit_to_user_mode_prepare+0xa5/0x1d0
__x64_sys_sendto+0x29/0x30
do_syscall_64+0x3b/0xc0
entry_SYSCALL_64_after_hwframe+0x44/0xae
There are two problems with the current code. First, setting xs->dev to NULL
before waiting for all users to stop using the socket is not correct. The
entry to the data plane functions xsk_poll(), xsk_sendmsg(), and xsk_recvmsg()
are all guarded by a test that xs->state is in the state XSK_BOUND and if not,
it returns right away. But one process might have passed this test but still
have not gotten to the point in which it uses xs->dev in the code. In this
interim, a second process executing xsk_unbind_dev() might have set xs->dev to
NULL which will lead to a crash for the first process. The solution here is
just to get rid of this NULL assignment since it is not used anymore. Before
commit 42fddcc7c64b ("xsk: use state member for socket synchronization"),
xs->dev was the gatekeeper to admit processes into the data plane functions,
but it was replaced with the state variable xs->state in the aforementioned
commit.
The second problem is that synchronize_net() does not wait for any process in
xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() to complete, which means that the
state they rely on might be cleaned up prematurely. This can happen when the
notifier gets called (at driver unload for example) as it uses xsk_unbind_dev().
Solve this by extending the RCU critical region from just the ndo_xsk_wakeup
to the whole functions mentioned above, so that both the test of xs->state ==
XSK_BOUND and the last use of any member of xs is covered by the RCU critical
section. This will guarantee that when synchronize_net() completes, there will
be no processes left executing xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() and
state can be cleaned up safely. Note that we need to drop the RCU lock for the
skb xmit path as it uses functions that might sleep. Due to this, we have to
retest the xs->state after we grab the mutex that protects the skb xmit code
from, among a number of things, an xsk_unbind_dev() being executed from the
notifier at the same time.
Fixes: 42fddcc7c64b ("xsk: use state member for socket synchronization")
Reported-by: Elza Mathew <elza.mathew@intel.com>
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Björn Töpel <bjorn@kernel.org>
Link: https://lore.kernel.org/bpf/20220228094552.10134-1-magnus.karlsson@gmail.com
2022-02-28 17:45:52 +08:00
|
|
|
static int xsk_sendmsg(struct socket *sock, struct msghdr *m, size_t total_len)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
ret = __xsk_sendmsg(sock, m, total_len);
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int __xsk_recvmsg(struct socket *sock, struct msghdr *m, size_t len, int flags)
|
2020-12-01 02:51:58 +08:00
|
|
|
{
|
|
|
|
bool need_wait = !(flags & MSG_DONTWAIT);
|
|
|
|
struct sock *sk = sock->sk;
|
|
|
|
struct xdp_sock *xs = xdp_sk(sk);
|
|
|
|
|
2020-12-07 16:20:08 +08:00
|
|
|
if (unlikely(!xsk_is_bound(xs)))
|
|
|
|
return -ENXIO;
|
2020-12-01 02:51:58 +08:00
|
|
|
if (unlikely(!(xs->dev->flags & IFF_UP)))
|
|
|
|
return -ENETDOWN;
|
|
|
|
if (unlikely(!xs->rx))
|
|
|
|
return -ENOBUFS;
|
|
|
|
if (unlikely(need_wait))
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
2020-12-01 02:52:00 +08:00
|
|
|
if (sk_can_busy_loop(sk))
|
|
|
|
sk_busy_loop(sk, 1); /* only support non-blocking sockets */
|
|
|
|
|
|
|
|
if (xsk_no_wakeup(sk))
|
|
|
|
return 0;
|
|
|
|
|
2020-12-01 02:51:58 +08:00
|
|
|
if (xs->pool->cached_need_wakeup & XDP_WAKEUP_RX && xs->zc)
|
|
|
|
return xsk_wakeup(xs, XDP_WAKEUP_RX);
|
|
|
|
return 0;
|
2018-05-02 19:01:34 +08:00
|
|
|
}
|
|
|
|
|
xsk: Fix race at socket teardown
Fix a race in the xsk socket teardown code that can lead to a NULL pointer
dereference splat. The current xsk unbind code in xsk_unbind_dev() starts by
setting xs->state to XSK_UNBOUND, sets xs->dev to NULL and then waits for any
NAPI processing to terminate using synchronize_net(). After that, the release
code starts to tear down the socket state and free allocated memory.
BUG: kernel NULL pointer dereference, address: 00000000000000c0
PGD 8000000932469067 P4D 8000000932469067 PUD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Tainted: G I 5.16.0+ #2
Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 03/09/2015
RIP: 0010:__xsk_sendmsg+0x2c/0x690
[...]
RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000040 RCX: ffff8d5fc632d258
RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800
RBP: ffffa2348bd13db0 R08: 0000000000000000 R09: 00007ffffffff000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800
R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000
FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0
Call Trace:
<TASK>
? aa_sk_perm+0x43/0x1b0
xsk_sendmsg+0xf0/0x110
sock_sendmsg+0x65/0x70
__sys_sendto+0x113/0x190
? debug_smp_processor_id+0x17/0x20
? fpregs_assert_state_consistent+0x23/0x50
? exit_to_user_mode_prepare+0xa5/0x1d0
__x64_sys_sendto+0x29/0x30
do_syscall_64+0x3b/0xc0
entry_SYSCALL_64_after_hwframe+0x44/0xae
There are two problems with the current code. First, setting xs->dev to NULL
before waiting for all users to stop using the socket is not correct. The
entry to the data plane functions xsk_poll(), xsk_sendmsg(), and xsk_recvmsg()
are all guarded by a test that xs->state is in the state XSK_BOUND and if not,
it returns right away. But one process might have passed this test but still
have not gotten to the point in which it uses xs->dev in the code. In this
interim, a second process executing xsk_unbind_dev() might have set xs->dev to
NULL which will lead to a crash for the first process. The solution here is
just to get rid of this NULL assignment since it is not used anymore. Before
commit 42fddcc7c64b ("xsk: use state member for socket synchronization"),
xs->dev was the gatekeeper to admit processes into the data plane functions,
but it was replaced with the state variable xs->state in the aforementioned
commit.
The second problem is that synchronize_net() does not wait for any process in
xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() to complete, which means that the
state they rely on might be cleaned up prematurely. This can happen when the
notifier gets called (at driver unload for example) as it uses xsk_unbind_dev().
Solve this by extending the RCU critical region from just the ndo_xsk_wakeup
to the whole functions mentioned above, so that both the test of xs->state ==
XSK_BOUND and the last use of any member of xs is covered by the RCU critical
section. This will guarantee that when synchronize_net() completes, there will
be no processes left executing xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() and
state can be cleaned up safely. Note that we need to drop the RCU lock for the
skb xmit path as it uses functions that might sleep. Due to this, we have to
retest the xs->state after we grab the mutex that protects the skb xmit code
from, among a number of things, an xsk_unbind_dev() being executed from the
notifier at the same time.
Fixes: 42fddcc7c64b ("xsk: use state member for socket synchronization")
Reported-by: Elza Mathew <elza.mathew@intel.com>
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Björn Töpel <bjorn@kernel.org>
Link: https://lore.kernel.org/bpf/20220228094552.10134-1-magnus.karlsson@gmail.com
2022-02-28 17:45:52 +08:00
|
|
|
static int xsk_recvmsg(struct socket *sock, struct msghdr *m, size_t len, int flags)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
ret = __xsk_recvmsg(sock, m, len, flags);
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2019-11-20 08:10:42 +08:00
|
|
|
static __poll_t xsk_poll(struct file *file, struct socket *sock,
|
2018-06-29 00:43:44 +08:00
|
|
|
struct poll_table_struct *wait)
|
2018-05-02 19:01:27 +08:00
|
|
|
{
|
2020-12-01 21:56:57 +08:00
|
|
|
__poll_t mask = 0;
|
2019-10-02 14:31:59 +08:00
|
|
|
struct sock *sk = sock->sk;
|
|
|
|
struct xdp_sock *xs = xdp_sk(sk);
|
2020-08-28 16:26:19 +08:00
|
|
|
struct xsk_buff_pool *pool;
|
xsk: use state member for socket synchronization
Prior the state variable was introduced by Ilya, the dev member was
used to determine whether the socket was bound or not. However, when
dev was read, proper SMP barriers and READ_ONCE were missing. In order
to address the missing barriers and READ_ONCE, we start using the
state variable as a point of synchronization. The state member
read/write is paired with proper SMP barriers, and from this follows
that the members described above does not need READ_ONCE if used in
conjunction with state check.
In all syscalls and the xsk_rcv path we check if state is
XSK_BOUND. If that is the case we do a SMP read barrier, and this
implies that the dev, umem and all rings are correctly setup. Note
that no READ_ONCE are needed for these variable if used when state is
XSK_BOUND (plus the read barrier).
To summarize: The members struct xdp_sock members dev, queue_id, umem,
fq, cq, tx, rx, and state were read lock-less, with incorrect barriers
and missing {READ, WRITE}_ONCE. Now, umem, fq, cq, tx, rx, and state
are read lock-less. When these members are updated, WRITE_ONCE is
used. When read, READ_ONCE are only used when read outside the control
mutex (e.g. mmap) or, not synchronized with the state member
(XSK_BOUND plus smp_rmb())
Note that dev and queue_id do not need a WRITE_ONCE or READ_ONCE, due
to the introduce state synchronization (XSK_BOUND plus smp_rmb()).
Introducing the state check also fixes a race, found by syzcaller, in
xsk_poll() where umem could be accessed when stale.
Suggested-by: Hillf Danton <hdanton@sina.com>
Reported-by: syzbot+c82697e3043781e08802@syzkaller.appspotmail.com
Fixes: 77cd0d7b3f25 ("xsk: add support for need_wakeup flag in AF_XDP rings")
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-09-04 19:49:12 +08:00
|
|
|
|
2021-12-17 22:56:46 +08:00
|
|
|
sock_poll_wait(file, sock, wait);
|
|
|
|
|
xsk: Fix race at socket teardown
Fix a race in the xsk socket teardown code that can lead to a NULL pointer
dereference splat. The current xsk unbind code in xsk_unbind_dev() starts by
setting xs->state to XSK_UNBOUND, sets xs->dev to NULL and then waits for any
NAPI processing to terminate using synchronize_net(). After that, the release
code starts to tear down the socket state and free allocated memory.
BUG: kernel NULL pointer dereference, address: 00000000000000c0
PGD 8000000932469067 P4D 8000000932469067 PUD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Tainted: G I 5.16.0+ #2
Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 03/09/2015
RIP: 0010:__xsk_sendmsg+0x2c/0x690
[...]
RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000040 RCX: ffff8d5fc632d258
RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800
RBP: ffffa2348bd13db0 R08: 0000000000000000 R09: 00007ffffffff000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800
R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000
FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0
Call Trace:
<TASK>
? aa_sk_perm+0x43/0x1b0
xsk_sendmsg+0xf0/0x110
sock_sendmsg+0x65/0x70
__sys_sendto+0x113/0x190
? debug_smp_processor_id+0x17/0x20
? fpregs_assert_state_consistent+0x23/0x50
? exit_to_user_mode_prepare+0xa5/0x1d0
__x64_sys_sendto+0x29/0x30
do_syscall_64+0x3b/0xc0
entry_SYSCALL_64_after_hwframe+0x44/0xae
There are two problems with the current code. First, setting xs->dev to NULL
before waiting for all users to stop using the socket is not correct. The
entry to the data plane functions xsk_poll(), xsk_sendmsg(), and xsk_recvmsg()
are all guarded by a test that xs->state is in the state XSK_BOUND and if not,
it returns right away. But one process might have passed this test but still
have not gotten to the point in which it uses xs->dev in the code. In this
interim, a second process executing xsk_unbind_dev() might have set xs->dev to
NULL which will lead to a crash for the first process. The solution here is
just to get rid of this NULL assignment since it is not used anymore. Before
commit 42fddcc7c64b ("xsk: use state member for socket synchronization"),
xs->dev was the gatekeeper to admit processes into the data plane functions,
but it was replaced with the state variable xs->state in the aforementioned
commit.
The second problem is that synchronize_net() does not wait for any process in
xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() to complete, which means that the
state they rely on might be cleaned up prematurely. This can happen when the
notifier gets called (at driver unload for example) as it uses xsk_unbind_dev().
Solve this by extending the RCU critical region from just the ndo_xsk_wakeup
to the whole functions mentioned above, so that both the test of xs->state ==
XSK_BOUND and the last use of any member of xs is covered by the RCU critical
section. This will guarantee that when synchronize_net() completes, there will
be no processes left executing xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() and
state can be cleaned up safely. Note that we need to drop the RCU lock for the
skb xmit path as it uses functions that might sleep. Due to this, we have to
retest the xs->state after we grab the mutex that protects the skb xmit code
from, among a number of things, an xsk_unbind_dev() being executed from the
notifier at the same time.
Fixes: 42fddcc7c64b ("xsk: use state member for socket synchronization")
Reported-by: Elza Mathew <elza.mathew@intel.com>
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Björn Töpel <bjorn@kernel.org>
Link: https://lore.kernel.org/bpf/20220228094552.10134-1-magnus.karlsson@gmail.com
2022-02-28 17:45:52 +08:00
|
|
|
rcu_read_lock();
|
|
|
|
if (unlikely(!xsk_is_bound(xs))) {
|
|
|
|
rcu_read_unlock();
|
xsk: use state member for socket synchronization
Prior the state variable was introduced by Ilya, the dev member was
used to determine whether the socket was bound or not. However, when
dev was read, proper SMP barriers and READ_ONCE were missing. In order
to address the missing barriers and READ_ONCE, we start using the
state variable as a point of synchronization. The state member
read/write is paired with proper SMP barriers, and from this follows
that the members described above does not need READ_ONCE if used in
conjunction with state check.
In all syscalls and the xsk_rcv path we check if state is
XSK_BOUND. If that is the case we do a SMP read barrier, and this
implies that the dev, umem and all rings are correctly setup. Note
that no READ_ONCE are needed for these variable if used when state is
XSK_BOUND (plus the read barrier).
To summarize: The members struct xdp_sock members dev, queue_id, umem,
fq, cq, tx, rx, and state were read lock-less, with incorrect barriers
and missing {READ, WRITE}_ONCE. Now, umem, fq, cq, tx, rx, and state
are read lock-less. When these members are updated, WRITE_ONCE is
used. When read, READ_ONCE are only used when read outside the control
mutex (e.g. mmap) or, not synchronized with the state member
(XSK_BOUND plus smp_rmb())
Note that dev and queue_id do not need a WRITE_ONCE or READ_ONCE, due
to the introduce state synchronization (XSK_BOUND plus smp_rmb()).
Introducing the state check also fixes a race, found by syzcaller, in
xsk_poll() where umem could be accessed when stale.
Suggested-by: Hillf Danton <hdanton@sina.com>
Reported-by: syzbot+c82697e3043781e08802@syzkaller.appspotmail.com
Fixes: 77cd0d7b3f25 ("xsk: add support for need_wakeup flag in AF_XDP rings")
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-09-04 19:49:12 +08:00
|
|
|
return mask;
|
xsk: Fix race at socket teardown
Fix a race in the xsk socket teardown code that can lead to a NULL pointer
dereference splat. The current xsk unbind code in xsk_unbind_dev() starts by
setting xs->state to XSK_UNBOUND, sets xs->dev to NULL and then waits for any
NAPI processing to terminate using synchronize_net(). After that, the release
code starts to tear down the socket state and free allocated memory.
BUG: kernel NULL pointer dereference, address: 00000000000000c0
PGD 8000000932469067 P4D 8000000932469067 PUD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Tainted: G I 5.16.0+ #2
Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 03/09/2015
RIP: 0010:__xsk_sendmsg+0x2c/0x690
[...]
RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000040 RCX: ffff8d5fc632d258
RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800
RBP: ffffa2348bd13db0 R08: 0000000000000000 R09: 00007ffffffff000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800
R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000
FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0
Call Trace:
<TASK>
? aa_sk_perm+0x43/0x1b0
xsk_sendmsg+0xf0/0x110
sock_sendmsg+0x65/0x70
__sys_sendto+0x113/0x190
? debug_smp_processor_id+0x17/0x20
? fpregs_assert_state_consistent+0x23/0x50
? exit_to_user_mode_prepare+0xa5/0x1d0
__x64_sys_sendto+0x29/0x30
do_syscall_64+0x3b/0xc0
entry_SYSCALL_64_after_hwframe+0x44/0xae
There are two problems with the current code. First, setting xs->dev to NULL
before waiting for all users to stop using the socket is not correct. The
entry to the data plane functions xsk_poll(), xsk_sendmsg(), and xsk_recvmsg()
are all guarded by a test that xs->state is in the state XSK_BOUND and if not,
it returns right away. But one process might have passed this test but still
have not gotten to the point in which it uses xs->dev in the code. In this
interim, a second process executing xsk_unbind_dev() might have set xs->dev to
NULL which will lead to a crash for the first process. The solution here is
just to get rid of this NULL assignment since it is not used anymore. Before
commit 42fddcc7c64b ("xsk: use state member for socket synchronization"),
xs->dev was the gatekeeper to admit processes into the data plane functions,
but it was replaced with the state variable xs->state in the aforementioned
commit.
The second problem is that synchronize_net() does not wait for any process in
xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() to complete, which means that the
state they rely on might be cleaned up prematurely. This can happen when the
notifier gets called (at driver unload for example) as it uses xsk_unbind_dev().
Solve this by extending the RCU critical region from just the ndo_xsk_wakeup
to the whole functions mentioned above, so that both the test of xs->state ==
XSK_BOUND and the last use of any member of xs is covered by the RCU critical
section. This will guarantee that when synchronize_net() completes, there will
be no processes left executing xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() and
state can be cleaned up safely. Note that we need to drop the RCU lock for the
skb xmit path as it uses functions that might sleep. Due to this, we have to
retest the xs->state after we grab the mutex that protects the skb xmit code
from, among a number of things, an xsk_unbind_dev() being executed from the
notifier at the same time.
Fixes: 42fddcc7c64b ("xsk: use state member for socket synchronization")
Reported-by: Elza Mathew <elza.mathew@intel.com>
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Björn Töpel <bjorn@kernel.org>
Link: https://lore.kernel.org/bpf/20220228094552.10134-1-magnus.karlsson@gmail.com
2022-02-28 17:45:52 +08:00
|
|
|
}
|
xsk: use state member for socket synchronization
Prior the state variable was introduced by Ilya, the dev member was
used to determine whether the socket was bound or not. However, when
dev was read, proper SMP barriers and READ_ONCE were missing. In order
to address the missing barriers and READ_ONCE, we start using the
state variable as a point of synchronization. The state member
read/write is paired with proper SMP barriers, and from this follows
that the members described above does not need READ_ONCE if used in
conjunction with state check.
In all syscalls and the xsk_rcv path we check if state is
XSK_BOUND. If that is the case we do a SMP read barrier, and this
implies that the dev, umem and all rings are correctly setup. Note
that no READ_ONCE are needed for these variable if used when state is
XSK_BOUND (plus the read barrier).
To summarize: The members struct xdp_sock members dev, queue_id, umem,
fq, cq, tx, rx, and state were read lock-less, with incorrect barriers
and missing {READ, WRITE}_ONCE. Now, umem, fq, cq, tx, rx, and state
are read lock-less. When these members are updated, WRITE_ONCE is
used. When read, READ_ONCE are only used when read outside the control
mutex (e.g. mmap) or, not synchronized with the state member
(XSK_BOUND plus smp_rmb())
Note that dev and queue_id do not need a WRITE_ONCE or READ_ONCE, due
to the introduce state synchronization (XSK_BOUND plus smp_rmb()).
Introducing the state check also fixes a race, found by syzcaller, in
xsk_poll() where umem could be accessed when stale.
Suggested-by: Hillf Danton <hdanton@sina.com>
Reported-by: syzbot+c82697e3043781e08802@syzkaller.appspotmail.com
Fixes: 77cd0d7b3f25 ("xsk: add support for need_wakeup flag in AF_XDP rings")
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-09-04 19:49:12 +08:00
|
|
|
|
2020-08-28 16:26:19 +08:00
|
|
|
pool = xs->pool;
|
xsk: add support for need_wakeup flag in AF_XDP rings
This commit adds support for a new flag called need_wakeup in the
AF_XDP Tx and fill rings. When this flag is set, it means that the
application has to explicitly wake up the kernel Rx (for the bit in
the fill ring) or kernel Tx (for bit in the Tx ring) processing by
issuing a syscall. Poll() can wake up both depending on the flags
submitted and sendto() will wake up tx processing only.
The main reason for introducing this new flag is to be able to
efficiently support the case when application and driver is executing
on the same core. Previously, the driver was just busy-spinning on the
fill ring if it ran out of buffers in the HW and there were none on
the fill ring. This approach works when the application is running on
another core as it can replenish the fill ring while the driver is
busy-spinning. Though, this is a lousy approach if both of them are
running on the same core as the probability of the fill ring getting
more entries when the driver is busy-spinning is zero. With this new
feature the driver now sets the need_wakeup flag and returns to the
application. The application can then replenish the fill queue and
then explicitly wake up the Rx processing in the kernel using the
syscall poll(). For Tx, the flag is only set to one if the driver has
no outstanding Tx completion interrupts. If it has some, the flag is
zero as it will be woken up by a completion interrupt anyway.
As a nice side effect, this new flag also improves the performance of
the case where application and driver are running on two different
cores as it reduces the number of syscalls to the kernel. The kernel
tells user space if it needs to be woken up by a syscall, and this
eliminates many of the syscalls.
This flag needs some simple driver support. If the driver does not
support this, the Rx flag is always zero and the Tx flag is always
one. This makes any application relying on this feature default to the
old behaviour of not requiring any syscalls in the Rx path and always
having to call sendto() in the Tx path.
For backwards compatibility reasons, this feature has to be explicitly
turned on using a new bind flag (XDP_USE_NEED_WAKEUP). I recommend
that you always turn it on as it so far always have had a positive
performance impact.
The name and inspiration of the flag has been taken from io_uring by
Jens Axboe. Details about this feature in io_uring can be found in
http://kernel.dk/io_uring.pdf, section 8.3.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-14 15:27:17 +08:00
|
|
|
|
2020-08-28 16:26:19 +08:00
|
|
|
if (pool->cached_need_wakeup) {
|
2019-12-18 00:20:42 +08:00
|
|
|
if (xs->zc)
|
2020-08-28 16:26:19 +08:00
|
|
|
xsk_wakeup(xs, pool->cached_need_wakeup);
|
2019-10-02 14:31:59 +08:00
|
|
|
else
|
|
|
|
/* Poll needs to drive Tx also in copy mode */
|
xsk: Fix race at socket teardown
Fix a race in the xsk socket teardown code that can lead to a NULL pointer
dereference splat. The current xsk unbind code in xsk_unbind_dev() starts by
setting xs->state to XSK_UNBOUND, sets xs->dev to NULL and then waits for any
NAPI processing to terminate using synchronize_net(). After that, the release
code starts to tear down the socket state and free allocated memory.
BUG: kernel NULL pointer dereference, address: 00000000000000c0
PGD 8000000932469067 P4D 8000000932469067 PUD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Tainted: G I 5.16.0+ #2
Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 03/09/2015
RIP: 0010:__xsk_sendmsg+0x2c/0x690
[...]
RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000040 RCX: ffff8d5fc632d258
RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800
RBP: ffffa2348bd13db0 R08: 0000000000000000 R09: 00007ffffffff000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800
R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000
FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0
Call Trace:
<TASK>
? aa_sk_perm+0x43/0x1b0
xsk_sendmsg+0xf0/0x110
sock_sendmsg+0x65/0x70
__sys_sendto+0x113/0x190
? debug_smp_processor_id+0x17/0x20
? fpregs_assert_state_consistent+0x23/0x50
? exit_to_user_mode_prepare+0xa5/0x1d0
__x64_sys_sendto+0x29/0x30
do_syscall_64+0x3b/0xc0
entry_SYSCALL_64_after_hwframe+0x44/0xae
There are two problems with the current code. First, setting xs->dev to NULL
before waiting for all users to stop using the socket is not correct. The
entry to the data plane functions xsk_poll(), xsk_sendmsg(), and xsk_recvmsg()
are all guarded by a test that xs->state is in the state XSK_BOUND and if not,
it returns right away. But one process might have passed this test but still
have not gotten to the point in which it uses xs->dev in the code. In this
interim, a second process executing xsk_unbind_dev() might have set xs->dev to
NULL which will lead to a crash for the first process. The solution here is
just to get rid of this NULL assignment since it is not used anymore. Before
commit 42fddcc7c64b ("xsk: use state member for socket synchronization"),
xs->dev was the gatekeeper to admit processes into the data plane functions,
but it was replaced with the state variable xs->state in the aforementioned
commit.
The second problem is that synchronize_net() does not wait for any process in
xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() to complete, which means that the
state they rely on might be cleaned up prematurely. This can happen when the
notifier gets called (at driver unload for example) as it uses xsk_unbind_dev().
Solve this by extending the RCU critical region from just the ndo_xsk_wakeup
to the whole functions mentioned above, so that both the test of xs->state ==
XSK_BOUND and the last use of any member of xs is covered by the RCU critical
section. This will guarantee that when synchronize_net() completes, there will
be no processes left executing xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() and
state can be cleaned up safely. Note that we need to drop the RCU lock for the
skb xmit path as it uses functions that might sleep. Due to this, we have to
retest the xs->state after we grab the mutex that protects the skb xmit code
from, among a number of things, an xsk_unbind_dev() being executed from the
notifier at the same time.
Fixes: 42fddcc7c64b ("xsk: use state member for socket synchronization")
Reported-by: Elza Mathew <elza.mathew@intel.com>
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Björn Töpel <bjorn@kernel.org>
Link: https://lore.kernel.org/bpf/20220228094552.10134-1-magnus.karlsson@gmail.com
2022-02-28 17:45:52 +08:00
|
|
|
xsk_xmit(sk);
|
2019-10-02 14:31:59 +08:00
|
|
|
}
|
2018-05-02 19:01:27 +08:00
|
|
|
|
2019-12-19 20:39:23 +08:00
|
|
|
if (xs->rx && !xskq_prod_is_empty(xs->rx))
|
2019-11-20 08:10:42 +08:00
|
|
|
mask |= EPOLLIN | EPOLLRDNORM;
|
2020-12-01 21:56:58 +08:00
|
|
|
if (xs->tx && xsk_tx_writeable(xs))
|
2019-11-20 08:10:42 +08:00
|
|
|
mask |= EPOLLOUT | EPOLLWRNORM;
|
2018-05-02 19:01:27 +08:00
|
|
|
|
xsk: Fix race at socket teardown
Fix a race in the xsk socket teardown code that can lead to a NULL pointer
dereference splat. The current xsk unbind code in xsk_unbind_dev() starts by
setting xs->state to XSK_UNBOUND, sets xs->dev to NULL and then waits for any
NAPI processing to terminate using synchronize_net(). After that, the release
code starts to tear down the socket state and free allocated memory.
BUG: kernel NULL pointer dereference, address: 00000000000000c0
PGD 8000000932469067 P4D 8000000932469067 PUD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Tainted: G I 5.16.0+ #2
Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 03/09/2015
RIP: 0010:__xsk_sendmsg+0x2c/0x690
[...]
RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000040 RCX: ffff8d5fc632d258
RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800
RBP: ffffa2348bd13db0 R08: 0000000000000000 R09: 00007ffffffff000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800
R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000
FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0
Call Trace:
<TASK>
? aa_sk_perm+0x43/0x1b0
xsk_sendmsg+0xf0/0x110
sock_sendmsg+0x65/0x70
__sys_sendto+0x113/0x190
? debug_smp_processor_id+0x17/0x20
? fpregs_assert_state_consistent+0x23/0x50
? exit_to_user_mode_prepare+0xa5/0x1d0
__x64_sys_sendto+0x29/0x30
do_syscall_64+0x3b/0xc0
entry_SYSCALL_64_after_hwframe+0x44/0xae
There are two problems with the current code. First, setting xs->dev to NULL
before waiting for all users to stop using the socket is not correct. The
entry to the data plane functions xsk_poll(), xsk_sendmsg(), and xsk_recvmsg()
are all guarded by a test that xs->state is in the state XSK_BOUND and if not,
it returns right away. But one process might have passed this test but still
have not gotten to the point in which it uses xs->dev in the code. In this
interim, a second process executing xsk_unbind_dev() might have set xs->dev to
NULL which will lead to a crash for the first process. The solution here is
just to get rid of this NULL assignment since it is not used anymore. Before
commit 42fddcc7c64b ("xsk: use state member for socket synchronization"),
xs->dev was the gatekeeper to admit processes into the data plane functions,
but it was replaced with the state variable xs->state in the aforementioned
commit.
The second problem is that synchronize_net() does not wait for any process in
xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() to complete, which means that the
state they rely on might be cleaned up prematurely. This can happen when the
notifier gets called (at driver unload for example) as it uses xsk_unbind_dev().
Solve this by extending the RCU critical region from just the ndo_xsk_wakeup
to the whole functions mentioned above, so that both the test of xs->state ==
XSK_BOUND and the last use of any member of xs is covered by the RCU critical
section. This will guarantee that when synchronize_net() completes, there will
be no processes left executing xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() and
state can be cleaned up safely. Note that we need to drop the RCU lock for the
skb xmit path as it uses functions that might sleep. Due to this, we have to
retest the xs->state after we grab the mutex that protects the skb xmit code
from, among a number of things, an xsk_unbind_dev() being executed from the
notifier at the same time.
Fixes: 42fddcc7c64b ("xsk: use state member for socket synchronization")
Reported-by: Elza Mathew <elza.mathew@intel.com>
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Björn Töpel <bjorn@kernel.org>
Link: https://lore.kernel.org/bpf/20220228094552.10134-1-magnus.karlsson@gmail.com
2022-02-28 17:45:52 +08:00
|
|
|
rcu_read_unlock();
|
2018-05-02 19:01:27 +08:00
|
|
|
return mask;
|
|
|
|
}
|
|
|
|
|
2018-05-02 19:01:25 +08:00
|
|
|
static int xsk_init_queue(u32 entries, struct xsk_queue **queue,
|
|
|
|
bool umem_queue)
|
2018-05-02 19:01:24 +08:00
|
|
|
{
|
|
|
|
struct xsk_queue *q;
|
|
|
|
|
|
|
|
if (entries == 0 || *queue || !is_power_of_2(entries))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2018-05-02 19:01:25 +08:00
|
|
|
q = xskq_create(entries, umem_queue);
|
2018-05-02 19:01:24 +08:00
|
|
|
if (!q)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2018-05-22 15:35:01 +08:00
|
|
|
/* Make sure queue is ready before it can be seen by others */
|
|
|
|
smp_wmb();
|
2019-09-04 19:49:10 +08:00
|
|
|
WRITE_ONCE(*queue, q);
|
2018-05-02 19:01:24 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-06-28 16:04:07 +08:00
|
|
|
static void xsk_unbind_dev(struct xdp_sock *xs)
|
|
|
|
{
|
|
|
|
struct net_device *dev = xs->dev;
|
|
|
|
|
xsk: use state member for socket synchronization
Prior the state variable was introduced by Ilya, the dev member was
used to determine whether the socket was bound or not. However, when
dev was read, proper SMP barriers and READ_ONCE were missing. In order
to address the missing barriers and READ_ONCE, we start using the
state variable as a point of synchronization. The state member
read/write is paired with proper SMP barriers, and from this follows
that the members described above does not need READ_ONCE if used in
conjunction with state check.
In all syscalls and the xsk_rcv path we check if state is
XSK_BOUND. If that is the case we do a SMP read barrier, and this
implies that the dev, umem and all rings are correctly setup. Note
that no READ_ONCE are needed for these variable if used when state is
XSK_BOUND (plus the read barrier).
To summarize: The members struct xdp_sock members dev, queue_id, umem,
fq, cq, tx, rx, and state were read lock-less, with incorrect barriers
and missing {READ, WRITE}_ONCE. Now, umem, fq, cq, tx, rx, and state
are read lock-less. When these members are updated, WRITE_ONCE is
used. When read, READ_ONCE are only used when read outside the control
mutex (e.g. mmap) or, not synchronized with the state member
(XSK_BOUND plus smp_rmb())
Note that dev and queue_id do not need a WRITE_ONCE or READ_ONCE, due
to the introduce state synchronization (XSK_BOUND plus smp_rmb()).
Introducing the state check also fixes a race, found by syzcaller, in
xsk_poll() where umem could be accessed when stale.
Suggested-by: Hillf Danton <hdanton@sina.com>
Reported-by: syzbot+c82697e3043781e08802@syzkaller.appspotmail.com
Fixes: 77cd0d7b3f25 ("xsk: add support for need_wakeup flag in AF_XDP rings")
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-09-04 19:49:12 +08:00
|
|
|
if (xs->state != XSK_BOUND)
|
2019-06-28 16:04:07 +08:00
|
|
|
return;
|
xsk: use state member for socket synchronization
Prior the state variable was introduced by Ilya, the dev member was
used to determine whether the socket was bound or not. However, when
dev was read, proper SMP barriers and READ_ONCE were missing. In order
to address the missing barriers and READ_ONCE, we start using the
state variable as a point of synchronization. The state member
read/write is paired with proper SMP barriers, and from this follows
that the members described above does not need READ_ONCE if used in
conjunction with state check.
In all syscalls and the xsk_rcv path we check if state is
XSK_BOUND. If that is the case we do a SMP read barrier, and this
implies that the dev, umem and all rings are correctly setup. Note
that no READ_ONCE are needed for these variable if used when state is
XSK_BOUND (plus the read barrier).
To summarize: The members struct xdp_sock members dev, queue_id, umem,
fq, cq, tx, rx, and state were read lock-less, with incorrect barriers
and missing {READ, WRITE}_ONCE. Now, umem, fq, cq, tx, rx, and state
are read lock-less. When these members are updated, WRITE_ONCE is
used. When read, READ_ONCE are only used when read outside the control
mutex (e.g. mmap) or, not synchronized with the state member
(XSK_BOUND plus smp_rmb())
Note that dev and queue_id do not need a WRITE_ONCE or READ_ONCE, due
to the introduce state synchronization (XSK_BOUND plus smp_rmb()).
Introducing the state check also fixes a race, found by syzcaller, in
xsk_poll() where umem could be accessed when stale.
Suggested-by: Hillf Danton <hdanton@sina.com>
Reported-by: syzbot+c82697e3043781e08802@syzkaller.appspotmail.com
Fixes: 77cd0d7b3f25 ("xsk: add support for need_wakeup flag in AF_XDP rings")
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-09-04 19:49:12 +08:00
|
|
|
WRITE_ONCE(xs->state, XSK_UNBOUND);
|
2019-06-28 16:04:07 +08:00
|
|
|
|
|
|
|
/* Wait for driver to stop using the xdp socket. */
|
2020-08-28 16:26:20 +08:00
|
|
|
xp_del_xsk(xs->pool, xs);
|
2019-06-28 16:04:07 +08:00
|
|
|
synchronize_net();
|
|
|
|
dev_put(dev);
|
|
|
|
}
|
|
|
|
|
2019-08-15 17:30:13 +08:00
|
|
|
static struct xsk_map *xsk_get_map_list_entry(struct xdp_sock *xs,
|
xdp: Add proper __rcu annotations to redirect map entries
XDP_REDIRECT works by a three-step process: the bpf_redirect() and
bpf_redirect_map() helpers will lookup the target of the redirect and store
it (along with some other metadata) in a per-CPU struct bpf_redirect_info.
Next, when the program returns the XDP_REDIRECT return code, the driver
will call xdp_do_redirect() which will use the information thus stored to
actually enqueue the frame into a bulk queue structure (that differs
slightly by map type, but shares the same principle). Finally, before
exiting its NAPI poll loop, the driver will call xdp_do_flush(), which will
flush all the different bulk queues, thus completing the redirect.
Pointers to the map entries will be kept around for this whole sequence of
steps, protected by RCU. However, there is no top-level rcu_read_lock() in
the core code; instead drivers add their own rcu_read_lock() around the XDP
portions of the code, but somewhat inconsistently as Martin discovered[0].
However, things still work because everything happens inside a single NAPI
poll sequence, which means it's between a pair of calls to
local_bh_disable()/local_bh_enable(). So Paul suggested[1] that we could
document this intention by using rcu_dereference_check() with
rcu_read_lock_bh_held() as a second parameter, thus allowing sparse and
lockdep to verify that everything is done correctly.
This patch does just that: we add an __rcu annotation to the map entry
pointers and remove the various comments explaining the NAPI poll assurance
strewn through devmap.c in favour of a longer explanation in filter.c. The
goal is to have one coherent documentation of the entire flow, and rely on
the RCU annotations as a "standard" way of communicating the flow in the
map code (which can additionally be understood by sparse and lockdep).
The RCU annotation replacements result in a fairly straight-forward
replacement where READ_ONCE() becomes rcu_dereference_check(), WRITE_ONCE()
becomes rcu_assign_pointer() and xchg() and cmpxchg() gets wrapped in the
proper constructs to cast the pointer back and forth between __rcu and
__kernel address space (for the benefit of sparse). The one complication is
that xskmap has a few constructions where double-pointers are passed back
and forth; these simply all gain __rcu annotations, and only the final
reference/dereference to the inner-most pointer gets changed.
With this, everything can be run through sparse without eliciting
complaints, and lockdep can verify correctness even without the use of
rcu_read_lock() in the drivers. Subsequent patches will clean these up from
the drivers.
[0] https://lore.kernel.org/bpf/20210415173551.7ma4slcbqeyiba2r@kafai-mbp.dhcp.thefacebook.com/
[1] https://lore.kernel.org/bpf/20210419165837.GA975577@paulmck-ThinkPad-P17-Gen-1/
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20210624160609.292325-6-toke@redhat.com
2021-06-25 00:05:55 +08:00
|
|
|
struct xdp_sock __rcu ***map_entry)
|
2019-08-15 17:30:13 +08:00
|
|
|
{
|
|
|
|
struct xsk_map *map = NULL;
|
|
|
|
struct xsk_map_node *node;
|
|
|
|
|
|
|
|
*map_entry = NULL;
|
|
|
|
|
|
|
|
spin_lock_bh(&xs->map_list_lock);
|
|
|
|
node = list_first_entry_or_null(&xs->map_list, struct xsk_map_node,
|
|
|
|
node);
|
|
|
|
if (node) {
|
2020-11-26 23:03:18 +08:00
|
|
|
bpf_map_inc(&node->map->map);
|
2019-08-15 17:30:13 +08:00
|
|
|
map = node->map;
|
|
|
|
*map_entry = node->map_entry;
|
|
|
|
}
|
|
|
|
spin_unlock_bh(&xs->map_list_lock);
|
|
|
|
return map;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void xsk_delete_from_maps(struct xdp_sock *xs)
|
|
|
|
{
|
|
|
|
/* This function removes the current XDP socket from all the
|
|
|
|
* maps it resides in. We need to take extra care here, due to
|
|
|
|
* the two locks involved. Each map has a lock synchronizing
|
|
|
|
* updates to the entries, and each socket has a lock that
|
|
|
|
* synchronizes access to the list of maps (map_list). For
|
|
|
|
* deadlock avoidance the locks need to be taken in the order
|
|
|
|
* "map lock"->"socket map list lock". We start off by
|
|
|
|
* accessing the socket map list, and take a reference to the
|
|
|
|
* map to guarantee existence between the
|
|
|
|
* xsk_get_map_list_entry() and xsk_map_try_sock_delete()
|
|
|
|
* calls. Then we ask the map to remove the socket, which
|
|
|
|
* tries to remove the socket from the map. Note that there
|
|
|
|
* might be updates to the map between
|
|
|
|
* xsk_get_map_list_entry() and xsk_map_try_sock_delete().
|
|
|
|
*/
|
xdp: Add proper __rcu annotations to redirect map entries
XDP_REDIRECT works by a three-step process: the bpf_redirect() and
bpf_redirect_map() helpers will lookup the target of the redirect and store
it (along with some other metadata) in a per-CPU struct bpf_redirect_info.
Next, when the program returns the XDP_REDIRECT return code, the driver
will call xdp_do_redirect() which will use the information thus stored to
actually enqueue the frame into a bulk queue structure (that differs
slightly by map type, but shares the same principle). Finally, before
exiting its NAPI poll loop, the driver will call xdp_do_flush(), which will
flush all the different bulk queues, thus completing the redirect.
Pointers to the map entries will be kept around for this whole sequence of
steps, protected by RCU. However, there is no top-level rcu_read_lock() in
the core code; instead drivers add their own rcu_read_lock() around the XDP
portions of the code, but somewhat inconsistently as Martin discovered[0].
However, things still work because everything happens inside a single NAPI
poll sequence, which means it's between a pair of calls to
local_bh_disable()/local_bh_enable(). So Paul suggested[1] that we could
document this intention by using rcu_dereference_check() with
rcu_read_lock_bh_held() as a second parameter, thus allowing sparse and
lockdep to verify that everything is done correctly.
This patch does just that: we add an __rcu annotation to the map entry
pointers and remove the various comments explaining the NAPI poll assurance
strewn through devmap.c in favour of a longer explanation in filter.c. The
goal is to have one coherent documentation of the entire flow, and rely on
the RCU annotations as a "standard" way of communicating the flow in the
map code (which can additionally be understood by sparse and lockdep).
The RCU annotation replacements result in a fairly straight-forward
replacement where READ_ONCE() becomes rcu_dereference_check(), WRITE_ONCE()
becomes rcu_assign_pointer() and xchg() and cmpxchg() gets wrapped in the
proper constructs to cast the pointer back and forth between __rcu and
__kernel address space (for the benefit of sparse). The one complication is
that xskmap has a few constructions where double-pointers are passed back
and forth; these simply all gain __rcu annotations, and only the final
reference/dereference to the inner-most pointer gets changed.
With this, everything can be run through sparse without eliciting
complaints, and lockdep can verify correctness even without the use of
rcu_read_lock() in the drivers. Subsequent patches will clean these up from
the drivers.
[0] https://lore.kernel.org/bpf/20210415173551.7ma4slcbqeyiba2r@kafai-mbp.dhcp.thefacebook.com/
[1] https://lore.kernel.org/bpf/20210419165837.GA975577@paulmck-ThinkPad-P17-Gen-1/
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20210624160609.292325-6-toke@redhat.com
2021-06-25 00:05:55 +08:00
|
|
|
struct xdp_sock __rcu **map_entry = NULL;
|
2019-08-15 17:30:13 +08:00
|
|
|
struct xsk_map *map;
|
|
|
|
|
|
|
|
while ((map = xsk_get_map_list_entry(xs, &map_entry))) {
|
|
|
|
xsk_map_try_sock_delete(map, xs, map_entry);
|
2020-11-26 23:03:18 +08:00
|
|
|
bpf_map_put(&map->map);
|
2019-08-15 17:30:13 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-05-02 19:01:23 +08:00
|
|
|
static int xsk_release(struct socket *sock)
|
|
|
|
{
|
|
|
|
struct sock *sk = sock->sk;
|
2018-05-02 19:01:26 +08:00
|
|
|
struct xdp_sock *xs = xdp_sk(sk);
|
2018-05-02 19:01:23 +08:00
|
|
|
struct net *net;
|
|
|
|
|
|
|
|
if (!sk)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
net = sock_net(sk);
|
|
|
|
|
2019-01-25 02:59:37 +08:00
|
|
|
mutex_lock(&net->xdp.lock);
|
|
|
|
sk_del_node_init_rcu(sk);
|
|
|
|
mutex_unlock(&net->xdp.lock);
|
|
|
|
|
2018-05-02 19:01:23 +08:00
|
|
|
sock_prot_inuse_add(net, sk->sk_prot, -1);
|
|
|
|
|
2019-08-15 17:30:13 +08:00
|
|
|
xsk_delete_from_maps(xs);
|
xsk: use state member for socket synchronization
Prior the state variable was introduced by Ilya, the dev member was
used to determine whether the socket was bound or not. However, when
dev was read, proper SMP barriers and READ_ONCE were missing. In order
to address the missing barriers and READ_ONCE, we start using the
state variable as a point of synchronization. The state member
read/write is paired with proper SMP barriers, and from this follows
that the members described above does not need READ_ONCE if used in
conjunction with state check.
In all syscalls and the xsk_rcv path we check if state is
XSK_BOUND. If that is the case we do a SMP read barrier, and this
implies that the dev, umem and all rings are correctly setup. Note
that no READ_ONCE are needed for these variable if used when state is
XSK_BOUND (plus the read barrier).
To summarize: The members struct xdp_sock members dev, queue_id, umem,
fq, cq, tx, rx, and state were read lock-less, with incorrect barriers
and missing {READ, WRITE}_ONCE. Now, umem, fq, cq, tx, rx, and state
are read lock-less. When these members are updated, WRITE_ONCE is
used. When read, READ_ONCE are only used when read outside the control
mutex (e.g. mmap) or, not synchronized with the state member
(XSK_BOUND plus smp_rmb())
Note that dev and queue_id do not need a WRITE_ONCE or READ_ONCE, due
to the introduce state synchronization (XSK_BOUND plus smp_rmb()).
Introducing the state check also fixes a race, found by syzcaller, in
xsk_poll() where umem could be accessed when stale.
Suggested-by: Hillf Danton <hdanton@sina.com>
Reported-by: syzbot+c82697e3043781e08802@syzkaller.appspotmail.com
Fixes: 77cd0d7b3f25 ("xsk: add support for need_wakeup flag in AF_XDP rings")
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-09-04 19:49:12 +08:00
|
|
|
mutex_lock(&xs->mutex);
|
2019-06-28 16:04:07 +08:00
|
|
|
xsk_unbind_dev(xs);
|
xsk: use state member for socket synchronization
Prior the state variable was introduced by Ilya, the dev member was
used to determine whether the socket was bound or not. However, when
dev was read, proper SMP barriers and READ_ONCE were missing. In order
to address the missing barriers and READ_ONCE, we start using the
state variable as a point of synchronization. The state member
read/write is paired with proper SMP barriers, and from this follows
that the members described above does not need READ_ONCE if used in
conjunction with state check.
In all syscalls and the xsk_rcv path we check if state is
XSK_BOUND. If that is the case we do a SMP read barrier, and this
implies that the dev, umem and all rings are correctly setup. Note
that no READ_ONCE are needed for these variable if used when state is
XSK_BOUND (plus the read barrier).
To summarize: The members struct xdp_sock members dev, queue_id, umem,
fq, cq, tx, rx, and state were read lock-less, with incorrect barriers
and missing {READ, WRITE}_ONCE. Now, umem, fq, cq, tx, rx, and state
are read lock-less. When these members are updated, WRITE_ONCE is
used. When read, READ_ONCE are only used when read outside the control
mutex (e.g. mmap) or, not synchronized with the state member
(XSK_BOUND plus smp_rmb())
Note that dev and queue_id do not need a WRITE_ONCE or READ_ONCE, due
to the introduce state synchronization (XSK_BOUND plus smp_rmb()).
Introducing the state check also fixes a race, found by syzcaller, in
xsk_poll() where umem could be accessed when stale.
Suggested-by: Hillf Danton <hdanton@sina.com>
Reported-by: syzbot+c82697e3043781e08802@syzkaller.appspotmail.com
Fixes: 77cd0d7b3f25 ("xsk: add support for need_wakeup flag in AF_XDP rings")
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-09-04 19:49:12 +08:00
|
|
|
mutex_unlock(&xs->mutex);
|
2018-05-02 19:01:26 +08:00
|
|
|
|
2018-10-05 19:25:15 +08:00
|
|
|
xskq_destroy(xs->rx);
|
|
|
|
xskq_destroy(xs->tx);
|
2020-08-28 16:26:18 +08:00
|
|
|
xskq_destroy(xs->fq_tmp);
|
|
|
|
xskq_destroy(xs->cq_tmp);
|
2018-10-05 19:25:15 +08:00
|
|
|
|
2018-05-02 19:01:23 +08:00
|
|
|
sock_orphan(sk);
|
|
|
|
sock->sk = NULL;
|
|
|
|
|
|
|
|
sk_refcnt_debug_release(sk);
|
|
|
|
sock_put(sk);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-05-02 19:01:26 +08:00
|
|
|
static struct socket *xsk_lookup_xsk_from_fd(int fd)
|
|
|
|
{
|
|
|
|
struct socket *sock;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
sock = sockfd_lookup(fd, &err);
|
|
|
|
if (!sock)
|
|
|
|
return ERR_PTR(-ENOTSOCK);
|
|
|
|
|
|
|
|
if (sock->sk->sk_family != PF_XDP) {
|
|
|
|
sockfd_put(sock);
|
|
|
|
return ERR_PTR(-ENOPROTOOPT);
|
|
|
|
}
|
|
|
|
|
|
|
|
return sock;
|
|
|
|
}
|
|
|
|
|
2020-08-28 16:26:18 +08:00
|
|
|
static bool xsk_validate_queues(struct xdp_sock *xs)
|
|
|
|
{
|
|
|
|
return xs->fq_tmp && xs->cq_tmp;
|
|
|
|
}
|
|
|
|
|
2018-05-02 19:01:26 +08:00
|
|
|
static int xsk_bind(struct socket *sock, struct sockaddr *addr, int addr_len)
|
|
|
|
{
|
|
|
|
struct sockaddr_xdp *sxdp = (struct sockaddr_xdp *)addr;
|
|
|
|
struct sock *sk = sock->sk;
|
|
|
|
struct xdp_sock *xs = xdp_sk(sk);
|
2018-05-22 15:34:56 +08:00
|
|
|
struct net_device *dev;
|
2018-06-04 20:05:55 +08:00
|
|
|
u32 flags, qid;
|
2018-05-02 19:01:26 +08:00
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
if (addr_len < sizeof(struct sockaddr_xdp))
|
|
|
|
return -EINVAL;
|
|
|
|
if (sxdp->sxdp_family != AF_XDP)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2019-03-08 15:57:26 +08:00
|
|
|
flags = sxdp->sxdp_flags;
|
xsk: add support for need_wakeup flag in AF_XDP rings
This commit adds support for a new flag called need_wakeup in the
AF_XDP Tx and fill rings. When this flag is set, it means that the
application has to explicitly wake up the kernel Rx (for the bit in
the fill ring) or kernel Tx (for bit in the Tx ring) processing by
issuing a syscall. Poll() can wake up both depending on the flags
submitted and sendto() will wake up tx processing only.
The main reason for introducing this new flag is to be able to
efficiently support the case when application and driver is executing
on the same core. Previously, the driver was just busy-spinning on the
fill ring if it ran out of buffers in the HW and there were none on
the fill ring. This approach works when the application is running on
another core as it can replenish the fill ring while the driver is
busy-spinning. Though, this is a lousy approach if both of them are
running on the same core as the probability of the fill ring getting
more entries when the driver is busy-spinning is zero. With this new
feature the driver now sets the need_wakeup flag and returns to the
application. The application can then replenish the fill queue and
then explicitly wake up the Rx processing in the kernel using the
syscall poll(). For Tx, the flag is only set to one if the driver has
no outstanding Tx completion interrupts. If it has some, the flag is
zero as it will be woken up by a completion interrupt anyway.
As a nice side effect, this new flag also improves the performance of
the case where application and driver are running on two different
cores as it reduces the number of syscalls to the kernel. The kernel
tells user space if it needs to be woken up by a syscall, and this
eliminates many of the syscalls.
This flag needs some simple driver support. If the driver does not
support this, the Rx flag is always zero and the Tx flag is always
one. This makes any application relying on this feature default to the
old behaviour of not requiring any syscalls in the Rx path and always
having to call sendto() in the Tx path.
For backwards compatibility reasons, this feature has to be explicitly
turned on using a new bind flag (XDP_USE_NEED_WAKEUP). I recommend
that you always turn it on as it so far always have had a positive
performance impact.
The name and inspiration of the flag has been taken from io_uring by
Jens Axboe. Details about this feature in io_uring can be found in
http://kernel.dk/io_uring.pdf, section 8.3.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-14 15:27:17 +08:00
|
|
|
if (flags & ~(XDP_SHARED_UMEM | XDP_COPY | XDP_ZEROCOPY |
|
|
|
|
XDP_USE_NEED_WAKEUP))
|
2019-03-08 15:57:26 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2019-07-08 19:03:44 +08:00
|
|
|
rtnl_lock();
|
2018-05-02 19:01:26 +08:00
|
|
|
mutex_lock(&xs->mutex);
|
2019-06-28 16:04:07 +08:00
|
|
|
if (xs->state != XSK_READY) {
|
2018-05-22 15:34:56 +08:00
|
|
|
err = -EBUSY;
|
|
|
|
goto out_release;
|
|
|
|
}
|
|
|
|
|
2018-05-02 19:01:26 +08:00
|
|
|
dev = dev_get_by_index(sock_net(sk), sxdp->sxdp_ifindex);
|
|
|
|
if (!dev) {
|
|
|
|
err = -ENODEV;
|
|
|
|
goto out_release;
|
|
|
|
}
|
|
|
|
|
2018-05-02 19:01:32 +08:00
|
|
|
if (!xs->rx && !xs->tx) {
|
2018-05-02 19:01:26 +08:00
|
|
|
err = -EINVAL;
|
|
|
|
goto out_unlock;
|
|
|
|
}
|
|
|
|
|
2018-06-04 20:05:55 +08:00
|
|
|
qid = sxdp->sxdp_queue_id;
|
|
|
|
|
|
|
|
if (flags & XDP_SHARED_UMEM) {
|
2018-05-02 19:01:26 +08:00
|
|
|
struct xdp_sock *umem_xs;
|
|
|
|
struct socket *sock;
|
|
|
|
|
xsk: add support for need_wakeup flag in AF_XDP rings
This commit adds support for a new flag called need_wakeup in the
AF_XDP Tx and fill rings. When this flag is set, it means that the
application has to explicitly wake up the kernel Rx (for the bit in
the fill ring) or kernel Tx (for bit in the Tx ring) processing by
issuing a syscall. Poll() can wake up both depending on the flags
submitted and sendto() will wake up tx processing only.
The main reason for introducing this new flag is to be able to
efficiently support the case when application and driver is executing
on the same core. Previously, the driver was just busy-spinning on the
fill ring if it ran out of buffers in the HW and there were none on
the fill ring. This approach works when the application is running on
another core as it can replenish the fill ring while the driver is
busy-spinning. Though, this is a lousy approach if both of them are
running on the same core as the probability of the fill ring getting
more entries when the driver is busy-spinning is zero. With this new
feature the driver now sets the need_wakeup flag and returns to the
application. The application can then replenish the fill queue and
then explicitly wake up the Rx processing in the kernel using the
syscall poll(). For Tx, the flag is only set to one if the driver has
no outstanding Tx completion interrupts. If it has some, the flag is
zero as it will be woken up by a completion interrupt anyway.
As a nice side effect, this new flag also improves the performance of
the case where application and driver are running on two different
cores as it reduces the number of syscalls to the kernel. The kernel
tells user space if it needs to be woken up by a syscall, and this
eliminates many of the syscalls.
This flag needs some simple driver support. If the driver does not
support this, the Rx flag is always zero and the Tx flag is always
one. This makes any application relying on this feature default to the
old behaviour of not requiring any syscalls in the Rx path and always
having to call sendto() in the Tx path.
For backwards compatibility reasons, this feature has to be explicitly
turned on using a new bind flag (XDP_USE_NEED_WAKEUP). I recommend
that you always turn it on as it so far always have had a positive
performance impact.
The name and inspiration of the flag has been taken from io_uring by
Jens Axboe. Details about this feature in io_uring can be found in
http://kernel.dk/io_uring.pdf, section 8.3.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-14 15:27:17 +08:00
|
|
|
if ((flags & XDP_COPY) || (flags & XDP_ZEROCOPY) ||
|
|
|
|
(flags & XDP_USE_NEED_WAKEUP)) {
|
2018-06-04 20:05:55 +08:00
|
|
|
/* Cannot specify flags for shared sockets. */
|
|
|
|
err = -EINVAL;
|
|
|
|
goto out_unlock;
|
|
|
|
}
|
|
|
|
|
2018-05-02 19:01:26 +08:00
|
|
|
if (xs->umem) {
|
|
|
|
/* We have already our own. */
|
|
|
|
err = -EINVAL;
|
|
|
|
goto out_unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
sock = xsk_lookup_xsk_from_fd(sxdp->sxdp_shared_umem_fd);
|
|
|
|
if (IS_ERR(sock)) {
|
|
|
|
err = PTR_ERR(sock);
|
|
|
|
goto out_unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
umem_xs = xdp_sk(sock->sk);
|
xsk: use state member for socket synchronization
Prior the state variable was introduced by Ilya, the dev member was
used to determine whether the socket was bound or not. However, when
dev was read, proper SMP barriers and READ_ONCE were missing. In order
to address the missing barriers and READ_ONCE, we start using the
state variable as a point of synchronization. The state member
read/write is paired with proper SMP barriers, and from this follows
that the members described above does not need READ_ONCE if used in
conjunction with state check.
In all syscalls and the xsk_rcv path we check if state is
XSK_BOUND. If that is the case we do a SMP read barrier, and this
implies that the dev, umem and all rings are correctly setup. Note
that no READ_ONCE are needed for these variable if used when state is
XSK_BOUND (plus the read barrier).
To summarize: The members struct xdp_sock members dev, queue_id, umem,
fq, cq, tx, rx, and state were read lock-less, with incorrect barriers
and missing {READ, WRITE}_ONCE. Now, umem, fq, cq, tx, rx, and state
are read lock-less. When these members are updated, WRITE_ONCE is
used. When read, READ_ONCE are only used when read outside the control
mutex (e.g. mmap) or, not synchronized with the state member
(XSK_BOUND plus smp_rmb())
Note that dev and queue_id do not need a WRITE_ONCE or READ_ONCE, due
to the introduce state synchronization (XSK_BOUND plus smp_rmb()).
Introducing the state check also fixes a race, found by syzcaller, in
xsk_poll() where umem could be accessed when stale.
Suggested-by: Hillf Danton <hdanton@sina.com>
Reported-by: syzbot+c82697e3043781e08802@syzkaller.appspotmail.com
Fixes: 77cd0d7b3f25 ("xsk: add support for need_wakeup flag in AF_XDP rings")
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-09-04 19:49:12 +08:00
|
|
|
if (!xsk_is_bound(umem_xs)) {
|
2018-05-02 19:01:26 +08:00
|
|
|
err = -EBADF;
|
|
|
|
sockfd_put(sock);
|
|
|
|
goto out_unlock;
|
xsk: use state member for socket synchronization
Prior the state variable was introduced by Ilya, the dev member was
used to determine whether the socket was bound or not. However, when
dev was read, proper SMP barriers and READ_ONCE were missing. In order
to address the missing barriers and READ_ONCE, we start using the
state variable as a point of synchronization. The state member
read/write is paired with proper SMP barriers, and from this follows
that the members described above does not need READ_ONCE if used in
conjunction with state check.
In all syscalls and the xsk_rcv path we check if state is
XSK_BOUND. If that is the case we do a SMP read barrier, and this
implies that the dev, umem and all rings are correctly setup. Note
that no READ_ONCE are needed for these variable if used when state is
XSK_BOUND (plus the read barrier).
To summarize: The members struct xdp_sock members dev, queue_id, umem,
fq, cq, tx, rx, and state were read lock-less, with incorrect barriers
and missing {READ, WRITE}_ONCE. Now, umem, fq, cq, tx, rx, and state
are read lock-less. When these members are updated, WRITE_ONCE is
used. When read, READ_ONCE are only used when read outside the control
mutex (e.g. mmap) or, not synchronized with the state member
(XSK_BOUND plus smp_rmb())
Note that dev and queue_id do not need a WRITE_ONCE or READ_ONCE, due
to the introduce state synchronization (XSK_BOUND plus smp_rmb()).
Introducing the state check also fixes a race, found by syzcaller, in
xsk_poll() where umem could be accessed when stale.
Suggested-by: Hillf Danton <hdanton@sina.com>
Reported-by: syzbot+c82697e3043781e08802@syzkaller.appspotmail.com
Fixes: 77cd0d7b3f25 ("xsk: add support for need_wakeup flag in AF_XDP rings")
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-09-04 19:49:12 +08:00
|
|
|
}
|
2018-05-02 19:01:26 +08:00
|
|
|
|
2020-08-28 16:26:26 +08:00
|
|
|
if (umem_xs->queue_id != qid || umem_xs->dev != dev) {
|
|
|
|
/* Share the umem with another socket on another qid
|
|
|
|
* and/or device.
|
|
|
|
*/
|
2020-08-28 16:26:25 +08:00
|
|
|
xs->pool = xp_create_and_assign_umem(xs,
|
|
|
|
umem_xs->umem);
|
|
|
|
if (!xs->pool) {
|
2020-09-26 17:26:13 +08:00
|
|
|
err = -ENOMEM;
|
2020-08-28 16:26:25 +08:00
|
|
|
sockfd_put(sock);
|
|
|
|
goto out_unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = xp_assign_dev_shared(xs->pool, umem_xs->umem,
|
|
|
|
dev, qid);
|
|
|
|
if (err) {
|
|
|
|
xp_destroy(xs->pool);
|
2020-09-02 15:36:04 +08:00
|
|
|
xs->pool = NULL;
|
2020-08-28 16:26:25 +08:00
|
|
|
sockfd_put(sock);
|
|
|
|
goto out_unlock;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
/* Share the buffer pool with the other socket. */
|
|
|
|
if (xs->fq_tmp || xs->cq_tmp) {
|
|
|
|
/* Do not allow setting your own fq or cq. */
|
|
|
|
err = -EINVAL;
|
|
|
|
sockfd_put(sock);
|
|
|
|
goto out_unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
xp_get_pool(umem_xs->pool);
|
|
|
|
xs->pool = umem_xs->pool;
|
|
|
|
}
|
|
|
|
|
2018-05-02 19:01:26 +08:00
|
|
|
xdp_get_umem(umem_xs->umem);
|
2019-09-04 19:49:11 +08:00
|
|
|
WRITE_ONCE(xs->umem, umem_xs->umem);
|
2018-05-02 19:01:26 +08:00
|
|
|
sockfd_put(sock);
|
2020-08-28 16:26:18 +08:00
|
|
|
} else if (!xs->umem || !xsk_validate_queues(xs)) {
|
2018-05-02 19:01:26 +08:00
|
|
|
err = -EINVAL;
|
|
|
|
goto out_unlock;
|
2018-05-02 19:01:27 +08:00
|
|
|
} else {
|
|
|
|
/* This xsk has its own umem. */
|
2020-08-28 16:26:17 +08:00
|
|
|
xs->pool = xp_create_and_assign_umem(xs, xs->umem);
|
|
|
|
if (!xs->pool) {
|
|
|
|
err = -ENOMEM;
|
2018-06-04 20:05:55 +08:00
|
|
|
goto out_unlock;
|
2020-08-28 16:26:17 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
err = xp_assign_dev(xs->pool, dev, qid, flags);
|
|
|
|
if (err) {
|
|
|
|
xp_destroy(xs->pool);
|
|
|
|
xs->pool = NULL;
|
|
|
|
goto out_unlock;
|
|
|
|
}
|
2018-05-02 19:01:26 +08:00
|
|
|
}
|
|
|
|
|
2020-12-14 16:51:27 +08:00
|
|
|
/* FQ and CQ are now owned by the buffer pool and cleaned up with it. */
|
|
|
|
xs->fq_tmp = NULL;
|
|
|
|
xs->cq_tmp = NULL;
|
|
|
|
|
2018-05-02 19:01:26 +08:00
|
|
|
xs->dev = dev;
|
2018-06-04 20:05:57 +08:00
|
|
|
xs->zc = xs->umem->zc;
|
|
|
|
xs->queue_id = qid;
|
2020-08-28 16:26:20 +08:00
|
|
|
xp_add_xsk(xs->pool, xs);
|
2018-05-02 19:01:26 +08:00
|
|
|
|
|
|
|
out_unlock:
|
xsk: use state member for socket synchronization
Prior the state variable was introduced by Ilya, the dev member was
used to determine whether the socket was bound or not. However, when
dev was read, proper SMP barriers and READ_ONCE were missing. In order
to address the missing barriers and READ_ONCE, we start using the
state variable as a point of synchronization. The state member
read/write is paired with proper SMP barriers, and from this follows
that the members described above does not need READ_ONCE if used in
conjunction with state check.
In all syscalls and the xsk_rcv path we check if state is
XSK_BOUND. If that is the case we do a SMP read barrier, and this
implies that the dev, umem and all rings are correctly setup. Note
that no READ_ONCE are needed for these variable if used when state is
XSK_BOUND (plus the read barrier).
To summarize: The members struct xdp_sock members dev, queue_id, umem,
fq, cq, tx, rx, and state were read lock-less, with incorrect barriers
and missing {READ, WRITE}_ONCE. Now, umem, fq, cq, tx, rx, and state
are read lock-less. When these members are updated, WRITE_ONCE is
used. When read, READ_ONCE are only used when read outside the control
mutex (e.g. mmap) or, not synchronized with the state member
(XSK_BOUND plus smp_rmb())
Note that dev and queue_id do not need a WRITE_ONCE or READ_ONCE, due
to the introduce state synchronization (XSK_BOUND plus smp_rmb()).
Introducing the state check also fixes a race, found by syzcaller, in
xsk_poll() where umem could be accessed when stale.
Suggested-by: Hillf Danton <hdanton@sina.com>
Reported-by: syzbot+c82697e3043781e08802@syzkaller.appspotmail.com
Fixes: 77cd0d7b3f25 ("xsk: add support for need_wakeup flag in AF_XDP rings")
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-09-04 19:49:12 +08:00
|
|
|
if (err) {
|
2018-05-02 19:01:26 +08:00
|
|
|
dev_put(dev);
|
xsk: use state member for socket synchronization
Prior the state variable was introduced by Ilya, the dev member was
used to determine whether the socket was bound or not. However, when
dev was read, proper SMP barriers and READ_ONCE were missing. In order
to address the missing barriers and READ_ONCE, we start using the
state variable as a point of synchronization. The state member
read/write is paired with proper SMP barriers, and from this follows
that the members described above does not need READ_ONCE if used in
conjunction with state check.
In all syscalls and the xsk_rcv path we check if state is
XSK_BOUND. If that is the case we do a SMP read barrier, and this
implies that the dev, umem and all rings are correctly setup. Note
that no READ_ONCE are needed for these variable if used when state is
XSK_BOUND (plus the read barrier).
To summarize: The members struct xdp_sock members dev, queue_id, umem,
fq, cq, tx, rx, and state were read lock-less, with incorrect barriers
and missing {READ, WRITE}_ONCE. Now, umem, fq, cq, tx, rx, and state
are read lock-less. When these members are updated, WRITE_ONCE is
used. When read, READ_ONCE are only used when read outside the control
mutex (e.g. mmap) or, not synchronized with the state member
(XSK_BOUND plus smp_rmb())
Note that dev and queue_id do not need a WRITE_ONCE or READ_ONCE, due
to the introduce state synchronization (XSK_BOUND plus smp_rmb()).
Introducing the state check also fixes a race, found by syzcaller, in
xsk_poll() where umem could be accessed when stale.
Suggested-by: Hillf Danton <hdanton@sina.com>
Reported-by: syzbot+c82697e3043781e08802@syzkaller.appspotmail.com
Fixes: 77cd0d7b3f25 ("xsk: add support for need_wakeup flag in AF_XDP rings")
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-09-04 19:49:12 +08:00
|
|
|
} else {
|
|
|
|
/* Matches smp_rmb() in bind() for shared umem
|
|
|
|
* sockets, and xsk_is_bound().
|
|
|
|
*/
|
|
|
|
smp_wmb();
|
|
|
|
WRITE_ONCE(xs->state, XSK_BOUND);
|
|
|
|
}
|
2018-05-02 19:01:26 +08:00
|
|
|
out_release:
|
|
|
|
mutex_unlock(&xs->mutex);
|
2019-07-08 19:03:44 +08:00
|
|
|
rtnl_unlock();
|
2018-05-02 19:01:26 +08:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
xsk: add support to allow unaligned chunk placement
Currently, addresses are chunk size aligned. This means, we are very
restricted in terms of where we can place chunk within the umem. For
example, if we have a chunk size of 2k, then our chunks can only be placed
at 0,2k,4k,6k,8k... and so on (ie. every 2k starting from 0).
This patch introduces the ability to use unaligned chunks. With these
changes, we are no longer bound to having to place chunks at a 2k (or
whatever your chunk size is) interval. Since we are no longer dealing with
aligned chunks, they can now cross page boundaries. Checks for page
contiguity have been added in order to keep track of which pages are
followed by a physically contiguous page.
Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-27 10:25:22 +08:00
|
|
|
struct xdp_umem_reg_v1 {
|
|
|
|
__u64 addr; /* Start of packet data area */
|
|
|
|
__u64 len; /* Length of packet data area */
|
|
|
|
__u32 chunk_size;
|
|
|
|
__u32 headroom;
|
|
|
|
};
|
|
|
|
|
2018-05-02 19:01:23 +08:00
|
|
|
static int xsk_setsockopt(struct socket *sock, int level, int optname,
|
2020-07-23 14:09:07 +08:00
|
|
|
sockptr_t optval, unsigned int optlen)
|
2018-05-02 19:01:23 +08:00
|
|
|
{
|
|
|
|
struct sock *sk = sock->sk;
|
|
|
|
struct xdp_sock *xs = xdp_sk(sk);
|
|
|
|
int err;
|
|
|
|
|
|
|
|
if (level != SOL_XDP)
|
|
|
|
return -ENOPROTOOPT;
|
|
|
|
|
|
|
|
switch (optname) {
|
2018-05-02 19:01:25 +08:00
|
|
|
case XDP_RX_RING:
|
2018-05-02 19:01:32 +08:00
|
|
|
case XDP_TX_RING:
|
2018-05-02 19:01:25 +08:00
|
|
|
{
|
|
|
|
struct xsk_queue **q;
|
|
|
|
int entries;
|
|
|
|
|
|
|
|
if (optlen < sizeof(entries))
|
|
|
|
return -EINVAL;
|
2020-07-23 14:09:07 +08:00
|
|
|
if (copy_from_sockptr(&entries, optval, sizeof(entries)))
|
2018-05-02 19:01:25 +08:00
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
mutex_lock(&xs->mutex);
|
2019-06-28 16:04:07 +08:00
|
|
|
if (xs->state != XSK_READY) {
|
|
|
|
mutex_unlock(&xs->mutex);
|
|
|
|
return -EBUSY;
|
|
|
|
}
|
2018-05-02 19:01:32 +08:00
|
|
|
q = (optname == XDP_TX_RING) ? &xs->tx : &xs->rx;
|
2018-05-02 19:01:25 +08:00
|
|
|
err = xsk_init_queue(entries, q, false);
|
xsk: add support for need_wakeup flag in AF_XDP rings
This commit adds support for a new flag called need_wakeup in the
AF_XDP Tx and fill rings. When this flag is set, it means that the
application has to explicitly wake up the kernel Rx (for the bit in
the fill ring) or kernel Tx (for bit in the Tx ring) processing by
issuing a syscall. Poll() can wake up both depending on the flags
submitted and sendto() will wake up tx processing only.
The main reason for introducing this new flag is to be able to
efficiently support the case when application and driver is executing
on the same core. Previously, the driver was just busy-spinning on the
fill ring if it ran out of buffers in the HW and there were none on
the fill ring. This approach works when the application is running on
another core as it can replenish the fill ring while the driver is
busy-spinning. Though, this is a lousy approach if both of them are
running on the same core as the probability of the fill ring getting
more entries when the driver is busy-spinning is zero. With this new
feature the driver now sets the need_wakeup flag and returns to the
application. The application can then replenish the fill queue and
then explicitly wake up the Rx processing in the kernel using the
syscall poll(). For Tx, the flag is only set to one if the driver has
no outstanding Tx completion interrupts. If it has some, the flag is
zero as it will be woken up by a completion interrupt anyway.
As a nice side effect, this new flag also improves the performance of
the case where application and driver are running on two different
cores as it reduces the number of syscalls to the kernel. The kernel
tells user space if it needs to be woken up by a syscall, and this
eliminates many of the syscalls.
This flag needs some simple driver support. If the driver does not
support this, the Rx flag is always zero and the Tx flag is always
one. This makes any application relying on this feature default to the
old behaviour of not requiring any syscalls in the Rx path and always
having to call sendto() in the Tx path.
For backwards compatibility reasons, this feature has to be explicitly
turned on using a new bind flag (XDP_USE_NEED_WAKEUP). I recommend
that you always turn it on as it so far always have had a positive
performance impact.
The name and inspiration of the flag has been taken from io_uring by
Jens Axboe. Details about this feature in io_uring can be found in
http://kernel.dk/io_uring.pdf, section 8.3.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-14 15:27:17 +08:00
|
|
|
if (!err && optname == XDP_TX_RING)
|
|
|
|
/* Tx needs to be explicitly woken up the first time */
|
|
|
|
xs->tx->ring->flags |= XDP_RING_NEED_WAKEUP;
|
2018-05-02 19:01:25 +08:00
|
|
|
mutex_unlock(&xs->mutex);
|
|
|
|
return err;
|
|
|
|
}
|
2018-05-02 19:01:23 +08:00
|
|
|
case XDP_UMEM_REG:
|
|
|
|
{
|
xsk: add support to allow unaligned chunk placement
Currently, addresses are chunk size aligned. This means, we are very
restricted in terms of where we can place chunk within the umem. For
example, if we have a chunk size of 2k, then our chunks can only be placed
at 0,2k,4k,6k,8k... and so on (ie. every 2k starting from 0).
This patch introduces the ability to use unaligned chunks. With these
changes, we are no longer bound to having to place chunks at a 2k (or
whatever your chunk size is) interval. Since we are no longer dealing with
aligned chunks, they can now cross page boundaries. Checks for page
contiguity have been added in order to keep track of which pages are
followed by a physically contiguous page.
Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-27 10:25:22 +08:00
|
|
|
size_t mr_size = sizeof(struct xdp_umem_reg);
|
|
|
|
struct xdp_umem_reg mr = {};
|
2018-05-02 19:01:23 +08:00
|
|
|
struct xdp_umem *umem;
|
|
|
|
|
xsk: add support to allow unaligned chunk placement
Currently, addresses are chunk size aligned. This means, we are very
restricted in terms of where we can place chunk within the umem. For
example, if we have a chunk size of 2k, then our chunks can only be placed
at 0,2k,4k,6k,8k... and so on (ie. every 2k starting from 0).
This patch introduces the ability to use unaligned chunks. With these
changes, we are no longer bound to having to place chunks at a 2k (or
whatever your chunk size is) interval. Since we are no longer dealing with
aligned chunks, they can now cross page boundaries. Checks for page
contiguity have been added in order to keep track of which pages are
followed by a physically contiguous page.
Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-27 10:25:22 +08:00
|
|
|
if (optlen < sizeof(struct xdp_umem_reg_v1))
|
|
|
|
return -EINVAL;
|
|
|
|
else if (optlen < sizeof(mr))
|
|
|
|
mr_size = sizeof(struct xdp_umem_reg_v1);
|
|
|
|
|
2020-07-23 14:09:07 +08:00
|
|
|
if (copy_from_sockptr(&mr, optval, mr_size))
|
2018-05-02 19:01:23 +08:00
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
mutex_lock(&xs->mutex);
|
2019-06-28 16:04:07 +08:00
|
|
|
if (xs->state != XSK_READY || xs->umem) {
|
2018-05-22 15:35:02 +08:00
|
|
|
mutex_unlock(&xs->mutex);
|
|
|
|
return -EBUSY;
|
|
|
|
}
|
2018-05-02 19:01:23 +08:00
|
|
|
|
2018-05-22 15:35:02 +08:00
|
|
|
umem = xdp_umem_create(&mr);
|
|
|
|
if (IS_ERR(umem)) {
|
2018-05-02 19:01:23 +08:00
|
|
|
mutex_unlock(&xs->mutex);
|
2018-05-22 15:35:02 +08:00
|
|
|
return PTR_ERR(umem);
|
2018-05-02 19:01:23 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Make sure umem is ready before it can be seen by others */
|
|
|
|
smp_wmb();
|
2019-09-04 19:49:11 +08:00
|
|
|
WRITE_ONCE(xs->umem, umem);
|
2018-05-02 19:01:23 +08:00
|
|
|
mutex_unlock(&xs->mutex);
|
|
|
|
return 0;
|
|
|
|
}
|
2018-05-02 19:01:24 +08:00
|
|
|
case XDP_UMEM_FILL_RING:
|
2018-05-02 19:01:31 +08:00
|
|
|
case XDP_UMEM_COMPLETION_RING:
|
2018-05-02 19:01:24 +08:00
|
|
|
{
|
|
|
|
struct xsk_queue **q;
|
|
|
|
int entries;
|
|
|
|
|
2020-07-23 14:09:07 +08:00
|
|
|
if (copy_from_sockptr(&entries, optval, sizeof(entries)))
|
2018-05-02 19:01:24 +08:00
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
mutex_lock(&xs->mutex);
|
2019-06-28 16:04:07 +08:00
|
|
|
if (xs->state != XSK_READY) {
|
|
|
|
mutex_unlock(&xs->mutex);
|
|
|
|
return -EBUSY;
|
|
|
|
}
|
2018-05-22 15:35:02 +08:00
|
|
|
|
2020-08-28 16:26:18 +08:00
|
|
|
q = (optname == XDP_UMEM_FILL_RING) ? &xs->fq_tmp :
|
|
|
|
&xs->cq_tmp;
|
2018-05-02 19:01:25 +08:00
|
|
|
err = xsk_init_queue(entries, q, true);
|
2018-05-02 19:01:24 +08:00
|
|
|
mutex_unlock(&xs->mutex);
|
|
|
|
return err;
|
|
|
|
}
|
2018-05-02 19:01:23 +08:00
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return -ENOPROTOOPT;
|
|
|
|
}
|
|
|
|
|
xsk: add support for need_wakeup flag in AF_XDP rings
This commit adds support for a new flag called need_wakeup in the
AF_XDP Tx and fill rings. When this flag is set, it means that the
application has to explicitly wake up the kernel Rx (for the bit in
the fill ring) or kernel Tx (for bit in the Tx ring) processing by
issuing a syscall. Poll() can wake up both depending on the flags
submitted and sendto() will wake up tx processing only.
The main reason for introducing this new flag is to be able to
efficiently support the case when application and driver is executing
on the same core. Previously, the driver was just busy-spinning on the
fill ring if it ran out of buffers in the HW and there were none on
the fill ring. This approach works when the application is running on
another core as it can replenish the fill ring while the driver is
busy-spinning. Though, this is a lousy approach if both of them are
running on the same core as the probability of the fill ring getting
more entries when the driver is busy-spinning is zero. With this new
feature the driver now sets the need_wakeup flag and returns to the
application. The application can then replenish the fill queue and
then explicitly wake up the Rx processing in the kernel using the
syscall poll(). For Tx, the flag is only set to one if the driver has
no outstanding Tx completion interrupts. If it has some, the flag is
zero as it will be woken up by a completion interrupt anyway.
As a nice side effect, this new flag also improves the performance of
the case where application and driver are running on two different
cores as it reduces the number of syscalls to the kernel. The kernel
tells user space if it needs to be woken up by a syscall, and this
eliminates many of the syscalls.
This flag needs some simple driver support. If the driver does not
support this, the Rx flag is always zero and the Tx flag is always
one. This makes any application relying on this feature default to the
old behaviour of not requiring any syscalls in the Rx path and always
having to call sendto() in the Tx path.
For backwards compatibility reasons, this feature has to be explicitly
turned on using a new bind flag (XDP_USE_NEED_WAKEUP). I recommend
that you always turn it on as it so far always have had a positive
performance impact.
The name and inspiration of the flag has been taken from io_uring by
Jens Axboe. Details about this feature in io_uring can be found in
http://kernel.dk/io_uring.pdf, section 8.3.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-14 15:27:17 +08:00
|
|
|
static void xsk_enter_rxtx_offsets(struct xdp_ring_offset_v1 *ring)
|
|
|
|
{
|
|
|
|
ring->producer = offsetof(struct xdp_rxtx_ring, ptrs.producer);
|
|
|
|
ring->consumer = offsetof(struct xdp_rxtx_ring, ptrs.consumer);
|
|
|
|
ring->desc = offsetof(struct xdp_rxtx_ring, desc);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void xsk_enter_umem_offsets(struct xdp_ring_offset_v1 *ring)
|
|
|
|
{
|
|
|
|
ring->producer = offsetof(struct xdp_umem_ring, ptrs.producer);
|
|
|
|
ring->consumer = offsetof(struct xdp_umem_ring, ptrs.consumer);
|
|
|
|
ring->desc = offsetof(struct xdp_umem_ring, desc);
|
|
|
|
}
|
|
|
|
|
2020-07-08 15:28:33 +08:00
|
|
|
struct xdp_statistics_v1 {
|
|
|
|
__u64 rx_dropped;
|
|
|
|
__u64 rx_invalid_descs;
|
|
|
|
__u64 tx_invalid_descs;
|
|
|
|
};
|
|
|
|
|
2018-05-02 19:01:35 +08:00
|
|
|
static int xsk_getsockopt(struct socket *sock, int level, int optname,
|
|
|
|
char __user *optval, int __user *optlen)
|
|
|
|
{
|
|
|
|
struct sock *sk = sock->sk;
|
|
|
|
struct xdp_sock *xs = xdp_sk(sk);
|
|
|
|
int len;
|
|
|
|
|
|
|
|
if (level != SOL_XDP)
|
|
|
|
return -ENOPROTOOPT;
|
|
|
|
|
|
|
|
if (get_user(len, optlen))
|
|
|
|
return -EFAULT;
|
|
|
|
if (len < 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
switch (optname) {
|
|
|
|
case XDP_STATISTICS:
|
|
|
|
{
|
2020-07-28 13:36:04 +08:00
|
|
|
struct xdp_statistics stats = {};
|
2020-07-08 15:28:33 +08:00
|
|
|
bool extra_stats = true;
|
|
|
|
size_t stats_size;
|
2018-05-02 19:01:35 +08:00
|
|
|
|
2020-07-08 15:28:33 +08:00
|
|
|
if (len < sizeof(struct xdp_statistics_v1)) {
|
2018-05-02 19:01:35 +08:00
|
|
|
return -EINVAL;
|
2020-07-08 15:28:33 +08:00
|
|
|
} else if (len < sizeof(stats)) {
|
|
|
|
extra_stats = false;
|
|
|
|
stats_size = sizeof(struct xdp_statistics_v1);
|
|
|
|
} else {
|
|
|
|
stats_size = sizeof(stats);
|
|
|
|
}
|
2018-05-02 19:01:35 +08:00
|
|
|
|
|
|
|
mutex_lock(&xs->mutex);
|
|
|
|
stats.rx_dropped = xs->rx_dropped;
|
2020-07-08 15:28:33 +08:00
|
|
|
if (extra_stats) {
|
|
|
|
stats.rx_ring_full = xs->rx_queue_full;
|
|
|
|
stats.rx_fill_ring_empty_descs =
|
2020-08-28 16:26:18 +08:00
|
|
|
xs->pool ? xskq_nb_queue_empty_descs(xs->pool->fq) : 0;
|
2020-07-08 15:28:33 +08:00
|
|
|
stats.tx_ring_empty_descs = xskq_nb_queue_empty_descs(xs->tx);
|
|
|
|
} else {
|
|
|
|
stats.rx_dropped += xs->rx_queue_full;
|
|
|
|
}
|
2018-05-02 19:01:35 +08:00
|
|
|
stats.rx_invalid_descs = xskq_nb_invalid_descs(xs->rx);
|
|
|
|
stats.tx_invalid_descs = xskq_nb_invalid_descs(xs->tx);
|
|
|
|
mutex_unlock(&xs->mutex);
|
|
|
|
|
2020-07-08 15:28:33 +08:00
|
|
|
if (copy_to_user(optval, &stats, stats_size))
|
2018-05-02 19:01:35 +08:00
|
|
|
return -EFAULT;
|
2020-07-08 15:28:33 +08:00
|
|
|
if (put_user(stats_size, optlen))
|
2018-05-02 19:01:35 +08:00
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
xsk: remove explicit ring structure from uapi
In this commit we remove the explicit ring structure from the the
uapi. It is tricky for an uapi to depend on a certain L1 cache line
size, since it can differ for variants of the same architecture. Now,
we let the user application determine the offsets of the producer,
consumer and descriptors by asking the socket via getsockopt.
A typical flow would be (Rx ring):
struct xdp_mmap_offsets off;
struct xdp_desc *ring;
u32 *prod, *cons;
void *map;
...
getsockopt(fd, SOL_XDP, XDP_MMAP_OFFSETS, &off, &optlen);
map = mmap(NULL, off.rx.desc +
NUM_DESCS * sizeof(struct xdp_desc),
PROT_READ | PROT_WRITE,
MAP_SHARED | MAP_POPULATE, sfd,
XDP_PGOFF_RX_RING);
prod = map + off.rx.producer;
cons = map + off.rx.consumer;
ring = map + off.rx.desc;
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-05-22 15:34:59 +08:00
|
|
|
case XDP_MMAP_OFFSETS:
|
|
|
|
{
|
|
|
|
struct xdp_mmap_offsets off;
|
xsk: add support for need_wakeup flag in AF_XDP rings
This commit adds support for a new flag called need_wakeup in the
AF_XDP Tx and fill rings. When this flag is set, it means that the
application has to explicitly wake up the kernel Rx (for the bit in
the fill ring) or kernel Tx (for bit in the Tx ring) processing by
issuing a syscall. Poll() can wake up both depending on the flags
submitted and sendto() will wake up tx processing only.
The main reason for introducing this new flag is to be able to
efficiently support the case when application and driver is executing
on the same core. Previously, the driver was just busy-spinning on the
fill ring if it ran out of buffers in the HW and there were none on
the fill ring. This approach works when the application is running on
another core as it can replenish the fill ring while the driver is
busy-spinning. Though, this is a lousy approach if both of them are
running on the same core as the probability of the fill ring getting
more entries when the driver is busy-spinning is zero. With this new
feature the driver now sets the need_wakeup flag and returns to the
application. The application can then replenish the fill queue and
then explicitly wake up the Rx processing in the kernel using the
syscall poll(). For Tx, the flag is only set to one if the driver has
no outstanding Tx completion interrupts. If it has some, the flag is
zero as it will be woken up by a completion interrupt anyway.
As a nice side effect, this new flag also improves the performance of
the case where application and driver are running on two different
cores as it reduces the number of syscalls to the kernel. The kernel
tells user space if it needs to be woken up by a syscall, and this
eliminates many of the syscalls.
This flag needs some simple driver support. If the driver does not
support this, the Rx flag is always zero and the Tx flag is always
one. This makes any application relying on this feature default to the
old behaviour of not requiring any syscalls in the Rx path and always
having to call sendto() in the Tx path.
For backwards compatibility reasons, this feature has to be explicitly
turned on using a new bind flag (XDP_USE_NEED_WAKEUP). I recommend
that you always turn it on as it so far always have had a positive
performance impact.
The name and inspiration of the flag has been taken from io_uring by
Jens Axboe. Details about this feature in io_uring can be found in
http://kernel.dk/io_uring.pdf, section 8.3.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-14 15:27:17 +08:00
|
|
|
struct xdp_mmap_offsets_v1 off_v1;
|
|
|
|
bool flags_supported = true;
|
|
|
|
void *to_copy;
|
xsk: remove explicit ring structure from uapi
In this commit we remove the explicit ring structure from the the
uapi. It is tricky for an uapi to depend on a certain L1 cache line
size, since it can differ for variants of the same architecture. Now,
we let the user application determine the offsets of the producer,
consumer and descriptors by asking the socket via getsockopt.
A typical flow would be (Rx ring):
struct xdp_mmap_offsets off;
struct xdp_desc *ring;
u32 *prod, *cons;
void *map;
...
getsockopt(fd, SOL_XDP, XDP_MMAP_OFFSETS, &off, &optlen);
map = mmap(NULL, off.rx.desc +
NUM_DESCS * sizeof(struct xdp_desc),
PROT_READ | PROT_WRITE,
MAP_SHARED | MAP_POPULATE, sfd,
XDP_PGOFF_RX_RING);
prod = map + off.rx.producer;
cons = map + off.rx.consumer;
ring = map + off.rx.desc;
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-05-22 15:34:59 +08:00
|
|
|
|
xsk: add support for need_wakeup flag in AF_XDP rings
This commit adds support for a new flag called need_wakeup in the
AF_XDP Tx and fill rings. When this flag is set, it means that the
application has to explicitly wake up the kernel Rx (for the bit in
the fill ring) or kernel Tx (for bit in the Tx ring) processing by
issuing a syscall. Poll() can wake up both depending on the flags
submitted and sendto() will wake up tx processing only.
The main reason for introducing this new flag is to be able to
efficiently support the case when application and driver is executing
on the same core. Previously, the driver was just busy-spinning on the
fill ring if it ran out of buffers in the HW and there were none on
the fill ring. This approach works when the application is running on
another core as it can replenish the fill ring while the driver is
busy-spinning. Though, this is a lousy approach if both of them are
running on the same core as the probability of the fill ring getting
more entries when the driver is busy-spinning is zero. With this new
feature the driver now sets the need_wakeup flag and returns to the
application. The application can then replenish the fill queue and
then explicitly wake up the Rx processing in the kernel using the
syscall poll(). For Tx, the flag is only set to one if the driver has
no outstanding Tx completion interrupts. If it has some, the flag is
zero as it will be woken up by a completion interrupt anyway.
As a nice side effect, this new flag also improves the performance of
the case where application and driver are running on two different
cores as it reduces the number of syscalls to the kernel. The kernel
tells user space if it needs to be woken up by a syscall, and this
eliminates many of the syscalls.
This flag needs some simple driver support. If the driver does not
support this, the Rx flag is always zero and the Tx flag is always
one. This makes any application relying on this feature default to the
old behaviour of not requiring any syscalls in the Rx path and always
having to call sendto() in the Tx path.
For backwards compatibility reasons, this feature has to be explicitly
turned on using a new bind flag (XDP_USE_NEED_WAKEUP). I recommend
that you always turn it on as it so far always have had a positive
performance impact.
The name and inspiration of the flag has been taken from io_uring by
Jens Axboe. Details about this feature in io_uring can be found in
http://kernel.dk/io_uring.pdf, section 8.3.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-14 15:27:17 +08:00
|
|
|
if (len < sizeof(off_v1))
|
xsk: remove explicit ring structure from uapi
In this commit we remove the explicit ring structure from the the
uapi. It is tricky for an uapi to depend on a certain L1 cache line
size, since it can differ for variants of the same architecture. Now,
we let the user application determine the offsets of the producer,
consumer and descriptors by asking the socket via getsockopt.
A typical flow would be (Rx ring):
struct xdp_mmap_offsets off;
struct xdp_desc *ring;
u32 *prod, *cons;
void *map;
...
getsockopt(fd, SOL_XDP, XDP_MMAP_OFFSETS, &off, &optlen);
map = mmap(NULL, off.rx.desc +
NUM_DESCS * sizeof(struct xdp_desc),
PROT_READ | PROT_WRITE,
MAP_SHARED | MAP_POPULATE, sfd,
XDP_PGOFF_RX_RING);
prod = map + off.rx.producer;
cons = map + off.rx.consumer;
ring = map + off.rx.desc;
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-05-22 15:34:59 +08:00
|
|
|
return -EINVAL;
|
xsk: add support for need_wakeup flag in AF_XDP rings
This commit adds support for a new flag called need_wakeup in the
AF_XDP Tx and fill rings. When this flag is set, it means that the
application has to explicitly wake up the kernel Rx (for the bit in
the fill ring) or kernel Tx (for bit in the Tx ring) processing by
issuing a syscall. Poll() can wake up both depending on the flags
submitted and sendto() will wake up tx processing only.
The main reason for introducing this new flag is to be able to
efficiently support the case when application and driver is executing
on the same core. Previously, the driver was just busy-spinning on the
fill ring if it ran out of buffers in the HW and there were none on
the fill ring. This approach works when the application is running on
another core as it can replenish the fill ring while the driver is
busy-spinning. Though, this is a lousy approach if both of them are
running on the same core as the probability of the fill ring getting
more entries when the driver is busy-spinning is zero. With this new
feature the driver now sets the need_wakeup flag and returns to the
application. The application can then replenish the fill queue and
then explicitly wake up the Rx processing in the kernel using the
syscall poll(). For Tx, the flag is only set to one if the driver has
no outstanding Tx completion interrupts. If it has some, the flag is
zero as it will be woken up by a completion interrupt anyway.
As a nice side effect, this new flag also improves the performance of
the case where application and driver are running on two different
cores as it reduces the number of syscalls to the kernel. The kernel
tells user space if it needs to be woken up by a syscall, and this
eliminates many of the syscalls.
This flag needs some simple driver support. If the driver does not
support this, the Rx flag is always zero and the Tx flag is always
one. This makes any application relying on this feature default to the
old behaviour of not requiring any syscalls in the Rx path and always
having to call sendto() in the Tx path.
For backwards compatibility reasons, this feature has to be explicitly
turned on using a new bind flag (XDP_USE_NEED_WAKEUP). I recommend
that you always turn it on as it so far always have had a positive
performance impact.
The name and inspiration of the flag has been taken from io_uring by
Jens Axboe. Details about this feature in io_uring can be found in
http://kernel.dk/io_uring.pdf, section 8.3.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-14 15:27:17 +08:00
|
|
|
else if (len < sizeof(off))
|
|
|
|
flags_supported = false;
|
|
|
|
|
|
|
|
if (flags_supported) {
|
|
|
|
/* xdp_ring_offset is identical to xdp_ring_offset_v1
|
|
|
|
* except for the flags field added to the end.
|
|
|
|
*/
|
|
|
|
xsk_enter_rxtx_offsets((struct xdp_ring_offset_v1 *)
|
|
|
|
&off.rx);
|
|
|
|
xsk_enter_rxtx_offsets((struct xdp_ring_offset_v1 *)
|
|
|
|
&off.tx);
|
|
|
|
xsk_enter_umem_offsets((struct xdp_ring_offset_v1 *)
|
|
|
|
&off.fr);
|
|
|
|
xsk_enter_umem_offsets((struct xdp_ring_offset_v1 *)
|
|
|
|
&off.cr);
|
|
|
|
off.rx.flags = offsetof(struct xdp_rxtx_ring,
|
|
|
|
ptrs.flags);
|
|
|
|
off.tx.flags = offsetof(struct xdp_rxtx_ring,
|
|
|
|
ptrs.flags);
|
|
|
|
off.fr.flags = offsetof(struct xdp_umem_ring,
|
|
|
|
ptrs.flags);
|
|
|
|
off.cr.flags = offsetof(struct xdp_umem_ring,
|
|
|
|
ptrs.flags);
|
|
|
|
|
|
|
|
len = sizeof(off);
|
|
|
|
to_copy = &off;
|
|
|
|
} else {
|
|
|
|
xsk_enter_rxtx_offsets(&off_v1.rx);
|
|
|
|
xsk_enter_rxtx_offsets(&off_v1.tx);
|
|
|
|
xsk_enter_umem_offsets(&off_v1.fr);
|
|
|
|
xsk_enter_umem_offsets(&off_v1.cr);
|
|
|
|
|
|
|
|
len = sizeof(off_v1);
|
|
|
|
to_copy = &off_v1;
|
|
|
|
}
|
xsk: remove explicit ring structure from uapi
In this commit we remove the explicit ring structure from the the
uapi. It is tricky for an uapi to depend on a certain L1 cache line
size, since it can differ for variants of the same architecture. Now,
we let the user application determine the offsets of the producer,
consumer and descriptors by asking the socket via getsockopt.
A typical flow would be (Rx ring):
struct xdp_mmap_offsets off;
struct xdp_desc *ring;
u32 *prod, *cons;
void *map;
...
getsockopt(fd, SOL_XDP, XDP_MMAP_OFFSETS, &off, &optlen);
map = mmap(NULL, off.rx.desc +
NUM_DESCS * sizeof(struct xdp_desc),
PROT_READ | PROT_WRITE,
MAP_SHARED | MAP_POPULATE, sfd,
XDP_PGOFF_RX_RING);
prod = map + off.rx.producer;
cons = map + off.rx.consumer;
ring = map + off.rx.desc;
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-05-22 15:34:59 +08:00
|
|
|
|
xsk: add support for need_wakeup flag in AF_XDP rings
This commit adds support for a new flag called need_wakeup in the
AF_XDP Tx and fill rings. When this flag is set, it means that the
application has to explicitly wake up the kernel Rx (for the bit in
the fill ring) or kernel Tx (for bit in the Tx ring) processing by
issuing a syscall. Poll() can wake up both depending on the flags
submitted and sendto() will wake up tx processing only.
The main reason for introducing this new flag is to be able to
efficiently support the case when application and driver is executing
on the same core. Previously, the driver was just busy-spinning on the
fill ring if it ran out of buffers in the HW and there were none on
the fill ring. This approach works when the application is running on
another core as it can replenish the fill ring while the driver is
busy-spinning. Though, this is a lousy approach if both of them are
running on the same core as the probability of the fill ring getting
more entries when the driver is busy-spinning is zero. With this new
feature the driver now sets the need_wakeup flag and returns to the
application. The application can then replenish the fill queue and
then explicitly wake up the Rx processing in the kernel using the
syscall poll(). For Tx, the flag is only set to one if the driver has
no outstanding Tx completion interrupts. If it has some, the flag is
zero as it will be woken up by a completion interrupt anyway.
As a nice side effect, this new flag also improves the performance of
the case where application and driver are running on two different
cores as it reduces the number of syscalls to the kernel. The kernel
tells user space if it needs to be woken up by a syscall, and this
eliminates many of the syscalls.
This flag needs some simple driver support. If the driver does not
support this, the Rx flag is always zero and the Tx flag is always
one. This makes any application relying on this feature default to the
old behaviour of not requiring any syscalls in the Rx path and always
having to call sendto() in the Tx path.
For backwards compatibility reasons, this feature has to be explicitly
turned on using a new bind flag (XDP_USE_NEED_WAKEUP). I recommend
that you always turn it on as it so far always have had a positive
performance impact.
The name and inspiration of the flag has been taken from io_uring by
Jens Axboe. Details about this feature in io_uring can be found in
http://kernel.dk/io_uring.pdf, section 8.3.
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-14 15:27:17 +08:00
|
|
|
if (copy_to_user(optval, to_copy, len))
|
xsk: remove explicit ring structure from uapi
In this commit we remove the explicit ring structure from the the
uapi. It is tricky for an uapi to depend on a certain L1 cache line
size, since it can differ for variants of the same architecture. Now,
we let the user application determine the offsets of the producer,
consumer and descriptors by asking the socket via getsockopt.
A typical flow would be (Rx ring):
struct xdp_mmap_offsets off;
struct xdp_desc *ring;
u32 *prod, *cons;
void *map;
...
getsockopt(fd, SOL_XDP, XDP_MMAP_OFFSETS, &off, &optlen);
map = mmap(NULL, off.rx.desc +
NUM_DESCS * sizeof(struct xdp_desc),
PROT_READ | PROT_WRITE,
MAP_SHARED | MAP_POPULATE, sfd,
XDP_PGOFF_RX_RING);
prod = map + off.rx.producer;
cons = map + off.rx.consumer;
ring = map + off.rx.desc;
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-05-22 15:34:59 +08:00
|
|
|
return -EFAULT;
|
|
|
|
if (put_user(len, optlen))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2019-06-26 22:35:25 +08:00
|
|
|
case XDP_OPTIONS:
|
|
|
|
{
|
|
|
|
struct xdp_options opts = {};
|
|
|
|
|
|
|
|
if (len < sizeof(opts))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
mutex_lock(&xs->mutex);
|
|
|
|
if (xs->zc)
|
|
|
|
opts.flags |= XDP_OPTIONS_ZEROCOPY;
|
|
|
|
mutex_unlock(&xs->mutex);
|
|
|
|
|
|
|
|
len = sizeof(opts);
|
|
|
|
if (copy_to_user(optval, &opts, len))
|
|
|
|
return -EFAULT;
|
|
|
|
if (put_user(len, optlen))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2018-05-02 19:01:35 +08:00
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
|
|
|
|
2018-05-02 19:01:24 +08:00
|
|
|
static int xsk_mmap(struct file *file, struct socket *sock,
|
|
|
|
struct vm_area_struct *vma)
|
|
|
|
{
|
2018-06-07 21:37:34 +08:00
|
|
|
loff_t offset = (loff_t)vma->vm_pgoff << PAGE_SHIFT;
|
2018-05-02 19:01:24 +08:00
|
|
|
unsigned long size = vma->vm_end - vma->vm_start;
|
|
|
|
struct xdp_sock *xs = xdp_sk(sock->sk);
|
|
|
|
struct xsk_queue *q = NULL;
|
|
|
|
unsigned long pfn;
|
|
|
|
struct page *qpg;
|
|
|
|
|
xsk: use state member for socket synchronization
Prior the state variable was introduced by Ilya, the dev member was
used to determine whether the socket was bound or not. However, when
dev was read, proper SMP barriers and READ_ONCE were missing. In order
to address the missing barriers and READ_ONCE, we start using the
state variable as a point of synchronization. The state member
read/write is paired with proper SMP barriers, and from this follows
that the members described above does not need READ_ONCE if used in
conjunction with state check.
In all syscalls and the xsk_rcv path we check if state is
XSK_BOUND. If that is the case we do a SMP read barrier, and this
implies that the dev, umem and all rings are correctly setup. Note
that no READ_ONCE are needed for these variable if used when state is
XSK_BOUND (plus the read barrier).
To summarize: The members struct xdp_sock members dev, queue_id, umem,
fq, cq, tx, rx, and state were read lock-less, with incorrect barriers
and missing {READ, WRITE}_ONCE. Now, umem, fq, cq, tx, rx, and state
are read lock-less. When these members are updated, WRITE_ONCE is
used. When read, READ_ONCE are only used when read outside the control
mutex (e.g. mmap) or, not synchronized with the state member
(XSK_BOUND plus smp_rmb())
Note that dev and queue_id do not need a WRITE_ONCE or READ_ONCE, due
to the introduce state synchronization (XSK_BOUND plus smp_rmb()).
Introducing the state check also fixes a race, found by syzcaller, in
xsk_poll() where umem could be accessed when stale.
Suggested-by: Hillf Danton <hdanton@sina.com>
Reported-by: syzbot+c82697e3043781e08802@syzkaller.appspotmail.com
Fixes: 77cd0d7b3f25 ("xsk: add support for need_wakeup flag in AF_XDP rings")
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-09-04 19:49:12 +08:00
|
|
|
if (READ_ONCE(xs->state) != XSK_READY)
|
2019-06-28 16:04:07 +08:00
|
|
|
return -EBUSY;
|
|
|
|
|
2018-05-02 19:01:25 +08:00
|
|
|
if (offset == XDP_PGOFF_RX_RING) {
|
2018-05-22 15:35:01 +08:00
|
|
|
q = READ_ONCE(xs->rx);
|
2018-05-02 19:01:32 +08:00
|
|
|
} else if (offset == XDP_PGOFF_TX_RING) {
|
2018-05-22 15:35:01 +08:00
|
|
|
q = READ_ONCE(xs->tx);
|
2018-05-02 19:01:25 +08:00
|
|
|
} else {
|
2019-02-08 21:13:50 +08:00
|
|
|
/* Matches the smp_wmb() in XDP_UMEM_REG */
|
|
|
|
smp_rmb();
|
2018-05-02 19:01:25 +08:00
|
|
|
if (offset == XDP_UMEM_PGOFF_FILL_RING)
|
2020-08-28 16:26:18 +08:00
|
|
|
q = READ_ONCE(xs->fq_tmp);
|
2018-05-02 19:01:31 +08:00
|
|
|
else if (offset == XDP_UMEM_PGOFF_COMPLETION_RING)
|
2020-08-28 16:26:18 +08:00
|
|
|
q = READ_ONCE(xs->cq_tmp);
|
2018-05-02 19:01:25 +08:00
|
|
|
}
|
2018-05-02 19:01:24 +08:00
|
|
|
|
|
|
|
if (!q)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2019-02-08 21:13:50 +08:00
|
|
|
/* Matches the smp_wmb() in xsk_init_queue */
|
|
|
|
smp_rmb();
|
2018-05-02 19:01:24 +08:00
|
|
|
qpg = virt_to_head_page(q->ring);
|
2019-09-24 06:34:25 +08:00
|
|
|
if (size > page_size(qpg))
|
2018-05-02 19:01:24 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
pfn = virt_to_phys(q->ring) >> PAGE_SHIFT;
|
|
|
|
return remap_pfn_range(vma, vma->vm_start, pfn,
|
|
|
|
size, vma->vm_page_prot);
|
|
|
|
}
|
|
|
|
|
2019-06-28 16:04:07 +08:00
|
|
|
static int xsk_notifier(struct notifier_block *this,
|
|
|
|
unsigned long msg, void *ptr)
|
|
|
|
{
|
|
|
|
struct net_device *dev = netdev_notifier_info_to_dev(ptr);
|
|
|
|
struct net *net = dev_net(dev);
|
|
|
|
struct sock *sk;
|
|
|
|
|
|
|
|
switch (msg) {
|
|
|
|
case NETDEV_UNREGISTER:
|
|
|
|
mutex_lock(&net->xdp.lock);
|
|
|
|
sk_for_each(sk, &net->xdp.list) {
|
|
|
|
struct xdp_sock *xs = xdp_sk(sk);
|
|
|
|
|
|
|
|
mutex_lock(&xs->mutex);
|
|
|
|
if (xs->dev == dev) {
|
|
|
|
sk->sk_err = ENETDOWN;
|
|
|
|
if (!sock_flag(sk, SOCK_DEAD))
|
2021-06-28 06:48:21 +08:00
|
|
|
sk_error_report(sk);
|
2019-06-28 16:04:07 +08:00
|
|
|
|
|
|
|
xsk_unbind_dev(xs);
|
|
|
|
|
2020-08-28 16:26:17 +08:00
|
|
|
/* Clear device references. */
|
|
|
|
xp_clear_dev(xs->pool);
|
2019-06-28 16:04:07 +08:00
|
|
|
}
|
|
|
|
mutex_unlock(&xs->mutex);
|
|
|
|
}
|
|
|
|
mutex_unlock(&net->xdp.lock);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return NOTIFY_DONE;
|
|
|
|
}
|
|
|
|
|
2018-05-02 19:01:23 +08:00
|
|
|
static struct proto xsk_proto = {
|
|
|
|
.name = "XDP",
|
|
|
|
.owner = THIS_MODULE,
|
|
|
|
.obj_size = sizeof(struct xdp_sock),
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct proto_ops xsk_proto_ops = {
|
2018-05-18 20:00:24 +08:00
|
|
|
.family = PF_XDP,
|
|
|
|
.owner = THIS_MODULE,
|
|
|
|
.release = xsk_release,
|
|
|
|
.bind = xsk_bind,
|
|
|
|
.connect = sock_no_connect,
|
|
|
|
.socketpair = sock_no_socketpair,
|
|
|
|
.accept = sock_no_accept,
|
|
|
|
.getname = sock_no_getname,
|
2018-06-29 00:43:44 +08:00
|
|
|
.poll = xsk_poll,
|
2018-05-18 20:00:24 +08:00
|
|
|
.ioctl = sock_no_ioctl,
|
|
|
|
.listen = sock_no_listen,
|
|
|
|
.shutdown = sock_no_shutdown,
|
|
|
|
.setsockopt = xsk_setsockopt,
|
|
|
|
.getsockopt = xsk_getsockopt,
|
|
|
|
.sendmsg = xsk_sendmsg,
|
2020-12-01 02:51:58 +08:00
|
|
|
.recvmsg = xsk_recvmsg,
|
2018-05-18 20:00:24 +08:00
|
|
|
.mmap = xsk_mmap,
|
|
|
|
.sendpage = sock_no_sendpage,
|
2018-05-02 19:01:23 +08:00
|
|
|
};
|
|
|
|
|
2019-02-21 20:07:38 +08:00
|
|
|
static void xsk_destruct(struct sock *sk)
|
|
|
|
{
|
|
|
|
struct xdp_sock *xs = xdp_sk(sk);
|
|
|
|
|
|
|
|
if (!sock_flag(sk, SOCK_DEAD))
|
|
|
|
return;
|
|
|
|
|
2020-10-27 20:32:01 +08:00
|
|
|
if (!xp_put_pool(xs->pool))
|
xsk: Fix umem cleanup bug at socket destruct
Fix a bug that is triggered when a partially setup socket is
destroyed. For a fully setup socket, a socket that has been bound to a
device, the cleanup of the umem is performed at the end of the buffer
pool's cleanup work queue item. This has to be performed in a work
queue, and not in RCU cleanup, as it is doing a vunmap that cannot
execute in interrupt context. However, when a socket has only been
partially set up so that a umem has been created but the buffer pool
has not, the code erroneously directly calls the umem cleanup function
instead of using a work queue, and this leads to a BUG_ON() in
vunmap().
As there in this case is no buffer pool, we cannot use its work queue,
so we need to introduce a work queue for the umem and schedule this for
the cleanup. So in the case there is no pool, we are going to use the
umem's own work queue to schedule the cleanup. But if there is a
pool, the cleanup of the umem is still being performed by the pool's
work queue, as it is important that the umem is cleaned up after the
pool.
Fixes: e5e1a4bc916d ("xsk: Fix possible memory leak at socket close")
Reported-by: Marek Majtyka <marekx.majtyka@intel.com>
Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: Marek Majtyka <marekx.majtyka@intel.com>
Link: https://lore.kernel.org/bpf/1605873219-21629-1-git-send-email-magnus.karlsson@gmail.com
2020-11-20 19:53:39 +08:00
|
|
|
xdp_put_umem(xs->umem, !xs->pool);
|
2019-02-21 20:07:38 +08:00
|
|
|
|
|
|
|
sk_refcnt_debug_dec(sk);
|
|
|
|
}
|
|
|
|
|
2018-05-02 19:01:23 +08:00
|
|
|
static int xsk_create(struct net *net, struct socket *sock, int protocol,
|
|
|
|
int kern)
|
|
|
|
{
|
|
|
|
struct xdp_sock *xs;
|
2020-08-28 16:26:17 +08:00
|
|
|
struct sock *sk;
|
2018-05-02 19:01:23 +08:00
|
|
|
|
|
|
|
if (!ns_capable(net->user_ns, CAP_NET_RAW))
|
|
|
|
return -EPERM;
|
|
|
|
if (sock->type != SOCK_RAW)
|
|
|
|
return -ESOCKTNOSUPPORT;
|
|
|
|
|
|
|
|
if (protocol)
|
|
|
|
return -EPROTONOSUPPORT;
|
|
|
|
|
|
|
|
sock->state = SS_UNCONNECTED;
|
|
|
|
|
|
|
|
sk = sk_alloc(net, PF_XDP, GFP_KERNEL, &xsk_proto, kern);
|
|
|
|
if (!sk)
|
|
|
|
return -ENOBUFS;
|
|
|
|
|
|
|
|
sock->ops = &xsk_proto_ops;
|
|
|
|
|
|
|
|
sock_init_data(sock, sk);
|
|
|
|
|
|
|
|
sk->sk_family = PF_XDP;
|
|
|
|
|
2019-02-21 20:07:38 +08:00
|
|
|
sk->sk_destruct = xsk_destruct;
|
|
|
|
sk_refcnt_debug_inc(sk);
|
|
|
|
|
2018-10-09 01:40:16 +08:00
|
|
|
sock_set_flag(sk, SOCK_RCU_FREE);
|
|
|
|
|
2018-05-02 19:01:23 +08:00
|
|
|
xs = xdp_sk(sk);
|
2019-06-28 16:04:07 +08:00
|
|
|
xs->state = XSK_READY;
|
2018-05-02 19:01:23 +08:00
|
|
|
mutex_init(&xs->mutex);
|
2019-07-03 20:09:16 +08:00
|
|
|
spin_lock_init(&xs->rx_lock);
|
2018-05-02 19:01:23 +08:00
|
|
|
|
2019-08-15 17:30:13 +08:00
|
|
|
INIT_LIST_HEAD(&xs->map_list);
|
|
|
|
spin_lock_init(&xs->map_list_lock);
|
|
|
|
|
2019-01-25 02:59:37 +08:00
|
|
|
mutex_lock(&net->xdp.lock);
|
|
|
|
sk_add_node_rcu(sk, &net->xdp.list);
|
|
|
|
mutex_unlock(&net->xdp.lock);
|
|
|
|
|
2018-05-02 19:01:23 +08:00
|
|
|
sock_prot_inuse_add(net, &xsk_proto, 1);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct net_proto_family xsk_family_ops = {
|
|
|
|
.family = PF_XDP,
|
|
|
|
.create = xsk_create,
|
|
|
|
.owner = THIS_MODULE,
|
|
|
|
};
|
|
|
|
|
2019-06-28 16:04:07 +08:00
|
|
|
static struct notifier_block xsk_netdev_notifier = {
|
|
|
|
.notifier_call = xsk_notifier,
|
|
|
|
};
|
|
|
|
|
2019-01-25 02:59:37 +08:00
|
|
|
static int __net_init xsk_net_init(struct net *net)
|
|
|
|
{
|
|
|
|
mutex_init(&net->xdp.lock);
|
|
|
|
INIT_HLIST_HEAD(&net->xdp.list);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __net_exit xsk_net_exit(struct net *net)
|
|
|
|
{
|
|
|
|
WARN_ON_ONCE(!hlist_empty(&net->xdp.list));
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct pernet_operations xsk_net_ops = {
|
|
|
|
.init = xsk_net_init,
|
|
|
|
.exit = xsk_net_exit,
|
|
|
|
};
|
|
|
|
|
2018-05-02 19:01:23 +08:00
|
|
|
static int __init xsk_init(void)
|
|
|
|
{
|
2019-12-19 14:10:02 +08:00
|
|
|
int err, cpu;
|
2018-05-02 19:01:23 +08:00
|
|
|
|
|
|
|
err = proto_register(&xsk_proto, 0 /* no slab */);
|
|
|
|
if (err)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
err = sock_register(&xsk_family_ops);
|
|
|
|
if (err)
|
|
|
|
goto out_proto;
|
|
|
|
|
2019-01-25 02:59:37 +08:00
|
|
|
err = register_pernet_subsys(&xsk_net_ops);
|
|
|
|
if (err)
|
|
|
|
goto out_sk;
|
2019-06-28 16:04:07 +08:00
|
|
|
|
|
|
|
err = register_netdevice_notifier(&xsk_netdev_notifier);
|
|
|
|
if (err)
|
|
|
|
goto out_pernet;
|
|
|
|
|
2019-12-19 14:10:02 +08:00
|
|
|
for_each_possible_cpu(cpu)
|
|
|
|
INIT_LIST_HEAD(&per_cpu(xskmap_flush_list, cpu));
|
2018-05-02 19:01:23 +08:00
|
|
|
return 0;
|
|
|
|
|
2019-06-28 16:04:07 +08:00
|
|
|
out_pernet:
|
|
|
|
unregister_pernet_subsys(&xsk_net_ops);
|
2019-01-25 02:59:37 +08:00
|
|
|
out_sk:
|
|
|
|
sock_unregister(PF_XDP);
|
2018-05-02 19:01:23 +08:00
|
|
|
out_proto:
|
|
|
|
proto_unregister(&xsk_proto);
|
|
|
|
out:
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
fs_initcall(xsk_init);
|