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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <20250829140539.3840337-1-jackzxcui1989@163.com>
Date: Fri, 29 Aug 2025 22:05:39 +0800
From: Xin Zhao <jackzxcui1989@....com>
To: 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

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, 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?

Thanks
Xin Zhao