aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/syscall-counts.py
diff options
context:
space:
mode:
authorCong Wang <[email protected]>2022-11-13 16:51:19 -0800
committerPaolo Abeni <[email protected]>2022-11-15 12:42:26 +0100
commit5121197ecc5db58c07da95eb1ff82b98b121a221 (patch)
tree88035496d9ecd825ad38a68b7e47a95878058995 /tools/perf/scripts/python/syscall-counts.py
parent280c0f7cd0aa4d190619b18243110e052a90775c (diff)
kcm: close race conditions on sk_receive_queue
sk->sk_receive_queue is protected by skb queue lock, but for KCM sockets its RX path takes mux->rx_lock to protect more than just skb queue. However, kcm_recvmsg() still only grabs the skb queue lock, so race conditions still exist. We can teach kcm_recvmsg() to grab mux->rx_lock too but this would introduce a potential performance regression as struct kcm_mux can be shared by multiple KCM sockets. So we have to enforce skb queue lock in requeue_rx_msgs() and handle skb peek case carefully in kcm_wait_data(). Fortunately, skb_recv_datagram() already handles it nicely and is widely used by other sockets, we can just switch to skb_recv_datagram() after getting rid of the unnecessary sock lock in kcm_recvmsg() and kcm_splice_read(). Side note: SOCK_DONE is not used by KCM sockets, so it is safe to get rid of this check too. I ran the original syzbot reproducer for 30 min without seeing any issue. Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module") Reported-by: [email protected] Reported-by: shaozhengchao <[email protected]> Cc: Paolo Abeni <[email protected]> Cc: Tom Herbert <[email protected]> Signed-off-by: Cong Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/syscall-counts.py')
0 files changed, 0 insertions, 0 deletions