linux-kernel - Re: [PATCH net-next] flow_dissector: save computed hash in __skb_get_hash_symmetric

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: <B4079F8E-E823-4848-A3CE-81D319B1FC4F@nutanix.com>
Date: Tue, 2 Dec 2025 16:53:43 +0000
From: Jon Kohler <jon@...anix.com>
To: Ido Schimmel <idosch@...dia.com>
CC: "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet
	<edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni
	<pabeni@...hat.com>, Simon Horman <horms@...nel.org>,
        Cong Wang
	<xiyou.wangcong@...il.com>,
        Nicolas Dichtel <nicolas.dichtel@...nd.com>,
        Jason Wang <jasowang@...hat.com>,
        "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next] flow_dissector: save computed hash in
 __skb_get_hash_symmetric_net()



> On Nov 27, 2025, at 3:24 AM, Ido Schimmel <idosch@...dia.com> wrote:
> 
> On Wed, Nov 26, 2025 at 04:21:33PM +0000, Jon Kohler wrote:
>> What about a variant of this patch that had an arg like:
>> __skb_get_hash_symmetric(struct sk_buff *skb, bool save_hash)
>> 
>> Then we just make calls (like tun) opt in?
> 
> It will require changes in all the callers and I am not sure it's wise
> to change a common function for a single user. Why not just patch tun to
> call __skb_set_sw_hash(skb, hash, true)? IIUC, even in tun you only need
> it in two out of the four callers of __skb_get_hash_symmetric():
> tun_get_user() and tun_xdp_one() which both build an skb before
> injecting it into the Rx path.

I thought about that, but the nice bit about doing it like I have it
is that the flow keys / L4 hash bits are getting evaluated properly.

If we do it like you’ve suggested, we’re asserting that L4 hash is always
true, right?

How about another helper, that only tun consumes, which does all of these
things, such that the code still stays clean on the flow dissector side
and we don’t have to mess with any other callers?

That would be the middle ground between what you suggested and what I did

Thoughts?

Thanks,
Jon