From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Phil Sutter <phil@nwl.cc>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [nf PATCH v3] netfilter: nfnetlink: Fix for interrupted hook dumps
Date: Wed, 9 Sep 2026 02:34:01 +0200 [thread overview]
Message-ID: <aqCpea5w45dXZ3p1@chamomile> (raw)
In-Reply-To: <aqAUL70ynrF6cT0G@orbyte.nwl.cc>
On Tue, Sep 08, 2026 at 03:57:03PM +0200, Phil Sutter wrote:
> On Tue, Sep 08, 2026 at 02:41:05PM +0200, Pablo Neira Ayuso wrote:
> > On Tue, Sep 08, 2026 at 11:23:03AM +0200, Phil Sutter wrote:
> > > Hi Pablo,
> > >
> > > On Mon, Sep 07, 2026 at 08:19:47PM +0200, Pablo Neira Ayuso wrote:
> > > > On Fri, Sep 04, 2026 at 02:52:15PM +0200, Phil Sutter wrote:
> > > > > @@ -338,27 +337,47 @@ nfnl_hook_entries_head(u8 pf, unsigned int hook, struct net *net, const char *de
> > > > > }
> > > > >
> > > > > static int nfnl_hook_dump_nat(struct sk_buff *nlskb,
> > > > > - const struct nfnl_dump_hook_data *ctx,
> > > > > - const struct nf_hook_ops *ops,
> > > > > - int family, unsigned int seq)
> > > > > + struct netlink_callback *cb,
> > > > > + const struct nf_hook_ops *ops, int family)
> > > > > {
> > > > > struct nf_nat_lookup_hook_priv *priv = ops->priv;
> > > > > - struct nf_hook_entries *e = rcu_dereference(priv->entries);
> > > > > + struct nfnl_dump_hook_data *ctx = cb->data;
> > > > > + struct net *net = sock_net(nlskb->sk);
> > > > > struct nf_hook_ops **nat_ops;
> > > > > - int i, err;
> > > > > + unsigned int i = cb->args[1];
> > > > > + struct nf_hook_entries *e;
> > > > > + unsigned int base_seq;
> > > > > + int err = 0;
> > > > >
> > > > > + base_seq = smp_load_acquire(&net->nf.nat_hook_base_seq);
> > > >
> > > > Maybe annnotate this base sequence in the .start via:
> > > >
> > > > struct netlink_dump_control c = {
> > > > .start = ...;
> > > >
> > > > We should probably start doing this in other nfnetlink subsystems too.
> > > >
> > > > This will help catch an interference between two netlink recv() calls
> > > > which results in calling netlink_dump() which calls this function.
> > >
> > > I do not comprehend, sorry. The concurrent hook dumps have distinct cb
> > > buffers and net->nf.{nat_,}hook_base_seq is shared but read-only. How
> > > does the problematic interference happen?
> >
> > See nf_tables_dump_rules_start() for instance. It allocates the struct
> > nft_rule_dump_ctx, which is reachable through .start, .dump and .done
> > callbacks. I think it should be possible to annotate the current
> > base_seq at the beginning of the netlink dump from .start in a ctx
> > object. Then, use it from .dump to check if dump is consistent (ie.
> > turn on the NLM_F_DUMP_INTR flag).
> >
> > So, instead of fetching the current sequence from .dump like this:
> >
> > cb->seq = nft_base_seq(net);
> >
> > Use the sequence available in the new ctx object, ie. from .dump path
> > you do this:
> >
> > cb->seq = ctx->seq;
>
> But to detect a concurrent hook update between to .dump callback calls
> (if skb space was exceeded), the current value in per-net data has to
> be fetched, no? So this would have to look like this in .dump callback:
>
> | ctx->seq = nft_base_seq(net);
> | cb->seq = ctx->seq;
>
> Then I don't get the detour via struct nfnl_dump_hook_data. Or is it
> possible we get multiple concurrent dump requests on the same netlink
> socket and thus cb->seq (and cb->prev_seq) gets shared between them?
>
> > Because netlink_dump() is called for each userspace recv() call (netlink
> > delivers the chunked listing in several messages), this would allow
> > userspace to know that the listing is inconsistent, then optionally
> > retry.
> >
> > Makes sense to you?
>
> Not quite, sorry.
Right, I got confused by the LLM report.
Should be postpone bumping the seq also after array has been shrunk as
LLM suggest in the remove path? For consistency with the insert
operations, just bump sequence _after_ the datastructure update.
prev parent reply other threads:[~2026-09-09 0:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 12:52 [nf PATCH v3] netfilter: nfnetlink: Fix for interrupted hook dumps Phil Sutter
2026-09-07 18:19 ` Pablo Neira Ayuso
2026-09-08 9:23 ` Phil Sutter
2026-09-08 12:41 ` Pablo Neira Ayuso
2026-09-08 13:57 ` Phil Sutter
2026-09-09 0:34 ` Pablo Neira Ayuso [this message]
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=aqCpea5w45dXZ3p1@chamomile \
--to=pablo@netfilter.org \
--cc=netfilter-devel@vger.kernel.org \
--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.