linux-kernel - Re: [PATCH net-next v9] 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 for Android: free password hash cracker in your pocket

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

Message-ID: <willemdebruijn.kernel.3427046386018@gmail.com>
Date: Fri, 29 Aug 2025 14:01:14 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Xin Zhao <jackzxcui1989@....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 v9] net: af_packet: Use hrtimer to do the retire
 operation

Xin Zhao wrote:
> On Fri, 2025-08-29 at 7:16 +0800, Willem wrote:
> 
> > Overall I'm on-board with this version.
> > 
> > 
> > One remaining question is the intended behavior of kactive_blk_num (K)
> > and last_kactive_blk_num (L).
> > 
> > K is incremented on block close. L is set to match K on block open and
> > each timer. So the only time that they differ is if a block is closed
> > in tpacket_rcv and no new block could be opened.
> > 
> > The only use of L is that the core of the timer callback is skipped if
> > L != K. Based on the above that can only happen if a block was closed
> > in tpacket_rcv and no new block could be opened (because the ring is
> > full), so the ring is frozen. So it only skips the frozen part of the
> > timer callback. Until the next timeout. But why? If the queue is
> > frozen and the next block is no longer in use, just call
> > prb_open_block right away?
> > 
> > Unless I'm missing something, I think we can make that simplification.
> > Then we won't have to worry that the behavior changes after this
> > patch. It should be a separate precursor patch though.
> 
> 
> I followed what you said, I think we can directly remove the
> last_kactive_blk_num variable and all related logic. I have run the
> optimized code in our project and haven't encountered any issues.
> The only impact I can think of is that in tpacket_rcv, when discovering
> that the next block is still in use and cannot be opened, we originally
> needed to wait for interval time in the timer callback before checking
> again. Now, we will make that check earlier,

At the next timer callback, which might run immediately.

But importantly averaged it is at half the timer latency, which
is in the same ballpark.

> which may allow us to
> discover that the user has finished using the block sooner and open the
> block earlier. So it seems that the optimization does not cause any issues.
> 
> 
> 
> So what should I do next?
> 
> I submit a patch that removes last_kactive_blk_num, then wait the patch
> merged, and after that rebase to submit the current hrtimer patch?
> 
> or
> 
> I wait for you to submit the patch that removes last_kactive_blk_num, and
> then rebase to submit the new hrtimer patch?
> 
> or
> 
> I directly include this modification in the hrtimer patch in version 10?

My idea was 4: you send a patch series with both patches.

But either 1 or 2 are fine too.