xsk: fix bug when trying to use both copy and zero-copy on one queue id
authorMagnus Karlsson <magnus.karlsson@intel.com>
Mon, 1 Oct 2018 12:51:34 +0000 (14:51 +0200)
committerDaniel Borkmann <daniel@iogearbox.net>
Fri, 5 Oct 2018 07:31:00 +0000 (09:31 +0200)
commitc9b47cc1fabca533fb8ebaeb417778036c1ce27d
tree1687d3526971fb8b97343fd2bb941370ebc5b83c
parent661b8d1b0e3a745e25f05adef2ebd00d830eeea7
xsk: fix bug when trying to use both copy and zero-copy on one queue id

Previously, the xsk code did not record which umem was bound to a
specific queue id. This was not required if all drivers were zero-copy
enabled as this had to be recorded in the driver anyway. So if a user
tried to bind two umems to the same queue, the driver would say
no. But if copy-mode was first enabled and then zero-copy mode (or the
reverse order), we mistakenly enabled both of them on the same umem
leading to buggy behavior. The main culprit for this is that we did
not store the association of umem to queue id in the copy case and
only relied on the driver reporting this. As this relation was not
stored in the driver for copy mode (it does not rely on the AF_XDP
NDOs), this obviously could not work.

This patch fixes the problem by always recording the umem to queue id
relationship in the netdev_queue and netdev_rx_queue structs. This way
we always know what kind of umem has been bound to a queue id and can
act appropriately at bind time.

Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
net/xdp/xdp_umem.c
net/xdp/xdp_umem.h
net/xdp/xsk.c