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: <willemdebruijn.kernel.1cc75fc0f6dfe@gmail.com>
Date: Wed, 17 Sep 2025 15:07:15 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Kuniyuki Iwashima <kuniyu@...gle.com>, 
 Eric Dumazet <edumazet@...gle.com>
Cc: Willem de Bruijn <willemdebruijn.kernel@...il.com>, 
 "David S . Miller" <davem@...emloft.net>, 
 Jakub Kicinski <kuba@...nel.org>, 
 Paolo Abeni <pabeni@...hat.com>, 
 Simon Horman <horms@...nel.org>, 
 Willem de Bruijn <willemb@...gle.com>, 
 David Ahern <dsahern@...nel.org>, 
 netdev@...r.kernel.org, 
 eric.dumazet@...il.com
Subject: Re: [PATCH net-next 05/10] udp: refine __udp_enqueue_schedule_skb()
 test

Kuniyuki Iwashima wrote:
> On Wed, Sep 17, 2025 at 8:57 AM Eric Dumazet <edumazet@...gle.com> wrote:
> >
> > On Wed, Sep 17, 2025 at 8:00 AM Willem de Bruijn
> > <willemdebruijn.kernel@...il.com> wrote:
> > >
> > > Eric Dumazet wrote:
> > > > Commit 5a465a0da13e ("udp: Fix multiple wraparounds
> > > > of sk->sk_rmem_alloc.") allowed to slightly overshoot
> > > > sk->sk_rmem_alloc, when many cpus are trying
> > > > to feed packets to a common UDP socket.
> > > >
> > > > This patch, combined with the following one reduces
> > > > false sharing on the victim socket under DDOS.
> > >
> > > It also changes the behavior. There was likely a reason to allow
> > > at least one packet if the buffer is small. Kuniyuki?
> >
> > It should not change the behavior.
> >
> > rmem would be zero if there is no packet in the queue : We still
> > accept the incoming skb, regardless of its truesize.
> >
> > If there is any packet, rmem > 0
> 
> Agreed, this change should be fine.
> 
> The rule comes from 0fd7bac6b6157, and later 850cbaddb52d
> tried to be more strict but caused regression, and the condition
> was converted to the current form in 363dc73acacbb.
> 
> Reviewed-by: Kuniyuki Iwashima <kuniyu@...gle.com>

Interesting. Thanks both!

Reviewed-by: Willem de Bruijn <willemb@...gle.com>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ