All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Florian Westphal <fw@strlen.de>
Cc: Phil Sutter <phil@nwl.cc>,
	netfilter-devel@vger.kernel.org, Paolo Abeni <pabeni@redhat.com>
Subject: Re: [nf-next PATCH 2/4] netfilter: nfnetlink_hook: Deref hook entry using READ_ONCE()
Date: Thu, 9 Jul 2026 19:04:42 +0200	[thread overview]
Message-ID: <ak_Uqs2vUMK8XPIU@chamomile> (raw)
In-Reply-To: <ak-VvHgZDCI5nIzv@strlen.de>

On Thu, Jul 09, 2026 at 02:36:12PM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > Are we sure net/netfilter/core.c is safe to be walked over rcu in its
> > current state? Could the dummy_ops be exposed through nfnetlink_hook?
> 
> What do you mean with 'safe'?
> The walk is safe from memory safety point of view.
> 
> dummy_ops *can* be exposed.
> 
> Otherwise, hook unregister can fail when low on memory:
> ATM, in case we unregister hook and then fail to alloc the replacement
> blob (that is same as live one minus the removed hook) we leave the
> dummy stub in so old hook function is no longer executed and leave the
> outdated/stale blob in place.
> 
> One alternative to dummy-ops usage is to keep a spare blob around so we
> can avoid the new memory allocation when a hook goes away.
> 
> Then, on delete:
> 
> 1. use the spare (which is large enough) instead
>    and prepare the new blob (without removed fn).
> 2. swap the spare with live version.
> 3. attempt to allocate a new spare.
>    if that fails, force a synchronize_rcu() and make
>    the 'old' live the new spare.
>    Else, use the new spare and avoid the,
>    synchronize_rcu(), old-live is handed off to call_rcu.
> 
> Hook-add would always have to keep the size of the spare
> up to date, so it is always large enough to hold the
> current amount of live hooks.
> 
> Its a bit more work, but it avoids the need for dummy_ops.
> LLM should be able to generate the transformation patches.

Maybe a more simple way is to skip dummy_ops in the netlink dump so it
is not exposed to userspace, that's all.

  reply	other threads:[~2026-07-09 17:04 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-08 16:19 [nf-next PATCH 0/4] Address Sashiko review of NAT hook dump code Phil Sutter
2026-07-08 16:19 ` [nf-next PATCH 1/4] netfilter: nfnetlink_hook: Pass cb object to nfnl_hook_dump_nat() Phil Sutter
2026-07-08 16:19 ` [nf-next PATCH 2/4] netfilter: nfnetlink_hook: Deref hook entry using READ_ONCE() Phil Sutter
2026-07-09 12:07   ` Pablo Neira Ayuso
2026-07-09 12:36     ` Florian Westphal
2026-07-09 17:04       ` Pablo Neira Ayuso [this message]
2026-07-08 16:19 ` [nf-next PATCH 3/4] netfilter: nfnetlink_hook: Handle multipart NAT hook dumps Phil Sutter
2026-07-08 16:19 ` [nf-next PATCH 4/4] netfilter: nfnetlink_hook: Fix for concurrent NAT hooks dump and change Phil Sutter
2026-07-09 11:28   ` Phil Sutter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ak_Uqs2vUMK8XPIU@chamomile \
    --to=pablo@netfilter.org \
    --cc=fw@strlen.de \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=phil@nwl.cc \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.