[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aRX_VP61EqRM-8z7@strlen.de>
Date: Thu, 13 Nov 2025 16:55:00 +0100
From: Florian Westphal <fw@...len.de>
To: Scott Mitchell <scott.k.mitch1@...il.com>
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
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.
Powered by blists - more mailing lists