linux-kernel - Re: [PATCH v3] netfilter: nfnetlink_queue: optimize verdict lookup with hash table

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: <CAFn2buAJY0RpSBAevCVavq9cUkenBKe3QcnXFA+5qqiS=8z5rA@mail.gmail.com>
Date: Thu, 13 Nov 2025 08:15:46 -0800
From: Scott Mitchell <scott.k.mitch1@...il.com>
To: Florian Westphal <fw@...len.de>
Cc: pablo@...filter.org, kadlec@...filter.org, phil@....cc, 
	davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, 
	horms@...nel.org, netfilter-devel@...r.kernel.org, coreteam@...filter.org, 
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] netfilter: nfnetlink_queue: optimize verdict lookup
 with hash table

On Thu, Nov 13, 2025 at 7:55 AM Florian Westphal <fw@...len.de> wrote:
>
> Scott Mitchell <scott.k.mitch1@...il.com> wrote:
> > +static int
> > +nfqnl_hash_resize(struct nfqnl_instance *inst, u32 hash_size)
> > +{
> > +     struct hlist_head *new_hash, *old_hash;
> > +     struct nf_queue_entry *entry;
> > +     unsigned int h, hash_mask;
> > +
> > +     hash_size = nfqnl_normalize_hash_size(hash_size);
> > +     if (hash_size == inst->queue_hash_size)
> > +             return 0;
> > +
> > +     new_hash = kvcalloc(hash_size, sizeof(*new_hash), GFP_KERNEL_ACCOUNT);
>
> This doesn't work, please re-test with LOCKDEP enabled before sending
> next version.
>
> > +     inst->queue_hash = kvcalloc(hash_size, sizeof(*inst->queue_hash),
> > +                                 GFP_KERNEL_ACCOUNT);
>
> .. and this doesn't work either, we are holding rcu read lock and
> the queue instance spinlock, so we cannot do a sleeping allocation.
>
> That said, I don't see a compelling reason why rcu read lock is held
> here, but resolving that needs prep work :-/
>
> So there are only two choices:
> 1. add a prep patch that pushes the locks to where they are needed,
>    the rebase this patch on top
> 2. use GFP_ATOMIC like in v1 and update comment to say that
>    GFP_KERNEL_ACCOUNT would need more work to place allocations
>    outside of the locks.

I will go with option 2 to make incremental progress.