summaryrefslogtreecommitdiffstats
path: root/sound/firewire
diff options
context:
space:
mode:
authorMaxim Mikityanskiy <maximmi@mellanox.com>2020-06-01 16:03:44 +0300
committerSaeed Mahameed <saeedm@mellanox.com>2020-06-11 15:37:55 -0700
commit36d45fb9d2fdf348d778bfe73f0427db1c6f9bc7 (patch)
treeeee64985987f418de6272810b6c2c15fe3772e7f /sound/firewire
parent47a357de2b6b706af3c9471d5042f9ba8907031e (diff)
downloadlinux-36d45fb9d2fdf348d778bfe73f0427db1c6f9bc7.tar.gz
linux-36d45fb9d2fdf348d778bfe73f0427db1c6f9bc7.tar.bz2
linux-36d45fb9d2fdf348d778bfe73f0427db1c6f9bc7.zip
net/mlx5e: Fix repeated XSK usage on one channel
After an XSK is closed, the relevant structures in the channel are not zeroed. If an XSK is opened the second time on the same channel without recreating channels, the stray values in the structures will lead to incorrect operation of queues, which causes CQE errors, and the new socket doesn't work at all. This patch fixes the issue by explicitly zeroing XSK-related structs in the channel on XSK close. Note that those structs are zeroed on channel creation, and usually a configuration change (XDP program is set) happens on XSK open, which leads to recreating channels, so typical XSK usecases don't suffer from this issue. However, if XSKs are opened and closed on the same channel without removing the XDP program, this bug reproduces. Fixes: db05815b36cb ("net/mlx5e: Add XSK zero-copy support") Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Diffstat (limited to 'sound/firewire')
0 files changed, 0 insertions, 0 deletions