netdev - Re: [PATCH net-next v10 2/2] net: af_packet: Use hrtimer to do the retire operation

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] [day] [month] [year] [list]

Message-ID: <willemdebruijn.kernel.ebc40a51f82e@gmail.com>
Date: Fri, 05 Sep 2025 12:16:44 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Xin Zhao <jackzxcui1989@....com>, 
 kerneljasonxing@...il.com, 
 willemdebruijn.kernel@...il.com, 
 edumazet@...gle.com, 
 ferenc@...es.dev
Cc: davem@...emloft.net, 
 kuba@...nel.org, 
 pabeni@...hat.com, 
 horms@...nel.org, 
 netdev@...r.kernel.org, 
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v10 2/2] net: af_packet: Use hrtimer to do the
 retire operation

Xin Zhao wrote:
> On Fri, Sep 5, 2025 at 14:45 +0800 Jason Xing <kerneljasonxing@...il.com> wrote:
> 
> > BTW, I have to emphasize that after this patch, the hrtimer will run
> > periodically and unconditionally. As far as I know, it's not possible
> > to run hundreds and thousands packet sockets in production, so it
> > might not be a huge problem. Or else, numerous timers are likely to
> > cause spikes/jitters, especially when timeout is very small (which can
> > be 1ms timeout for HZ=1000 system). It would be great if you state the
> > possible side effects in the next version.
> 
> The original logic actually involves an unconditional restart in the timer's
> callback. You might be suggesting that if packets come in particularly fast,
> the original logic would reset the timeout when opening a new block in
> tpacket_rcv, so the timeout does not expire immediately. However, if packets
> arrive very quickly, it will also lead to frequent timeout resets, which can
> waste CPU resources.
> I will emphasize in the comments that the current hrtimer expiration logic
> is unconditional and periodic.

+1 that should suffice