Merge branch 'fix-oom-and-order-check-in-msg_zerocopy-selftest'
authorJakub Kicinski <kuba@kernel.org>
Thu, 4 Jul 2024 02:42:33 +0000 (19:42 -0700)
committerJakub Kicinski <kuba@kernel.org>
Thu, 4 Jul 2024 02:42:34 +0000 (19:42 -0700)
commitaa09b7e0c12e8d7a5e098fa8a45015beb00f5c20
tree8dab2a1deba2e5b400fe530036406893be3d39b2
parentf66738dccd235112888c5b078eaef80fc9c68cf8
parent7d6d8f0c8b700c9493f2839abccb6d29028b4219
Merge branch 'fix-oom-and-order-check-in-msg_zerocopy-selftest'

Zijian Zhang says:

====================
fix OOM and order check in msg_zerocopy selftest

In selftests/net/msg_zerocopy.c, it has a while loop keeps calling sendmsg
on a socket with MSG_ZEROCOPY flag, and it will recv the notifications
until the socket is not writable. Typically, it will start the receiving
process after around 30+ sendmsgs. However, as the introduction of commit
dfa2f0483360 ("tcp: get rid of sysctl_tcp_adv_win_scale"), the sender is
always writable and does not get any chance to run recv notifications.
The selftest always exits with OUT_OF_MEMORY because the memory used by
opt_skb exceeds the net.core.optmem_max. Meanwhile, it could be set to a
different value to trigger OOM on older kernels too.

Thus, we introduce "cfg_notification_limit" to force sender to receive
notifications after some number of sendmsgs.

And, we find that when lock debugging is on, notifications may not come in
order. Thus, we have order checking outputs managed by cfg_verbose, to
avoid too many outputs in this case.
====================

Link: https://patch.msgid.link/20240701225349.3395580-1-zijianzhang@bytedance.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>