netdev - Re: [PATCH net-next 2/3] selftests: fix OOM problem in msg

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANn89iLTiq-29ceiQHc2Mi4na+kRb9K-MA1hGMn=G0ek6-mfjQ@mail.gmail.com>
Date: Tue, 9 Apr 2024 23:30:12 +0200
From: Eric Dumazet <edumazet@...gle.com>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: zijianzhang@...edance.com, netdev@...r.kernel.org, davem@...emloft.net, 
	kuba@...nel.org, cong.wang@...edance.com, xiaochun.lu@...edance.com
Subject: Re: [PATCH net-next 2/3] selftests: fix OOM problem in msg_zerocopy selftest

On Tue, Apr 9, 2024 at 11:25 PM Willem de Bruijn
<willemdebruijn.kernel@...il.com> wrote:
>
> zijianzhang@ wrote:
> > From: Zijian Zhang <zijianzhang@...edance.com>
> >
> > In selftests/net/msg_zerocopy.c, it has a while loop keeps calling sendmsg
> > on a socket, and it will recv the completion notifications when the socket
> > is not writable. Typically, it will start the receiving process after
> > around 30+ sendmsgs.
> >
> > However, because of the 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 core.sysctl_optmem_max. We introduce "cfg_notification_limit" to
> > force sender to receive notifications after some number of sendmsgs.
>
> No need for a new option. Existing test automation will not enable
> that.
>
> I have not observed this behavior in tests (so I wonder what is
> different about the setups). But it is fine to unconditionally force
> a call to do_recv_completions every few sends.

Maybe their kernel does not have yet :

commit 4944566706b27918ca15eda913889db296792415    net: increase
optmem_max default value

???

>
> > Plus,
> > in the selftest, we need to update skb_orphan_frags_rx to be the same as
> > skb_orphan_frags.
>
> To be able to test over loopback, I suppose?
>
> > In this case, for some reason, notifications do not
> > come in order now. We introduce "cfg_notification_order_check" to
> > possibly ignore the checking for order.
>
> Were you testing UDP?
>
> I don't think this is needed. I wonder what you were doing to see
> enough of these events to want to suppress the log output.