From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Florian Westphal <fw@strlen.de>
Cc: Fernando Fernandez Mancera <fmancera@suse.de>,
netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
phil@nwl.cc
Subject: Re: [PATCH 4/9 nf-next] netfilter: conntrack: use DEBUG_NET_WARN_ON_ONCE on packet paths
Date: Thu, 18 Jun 2026 20:15:06 +0200 [thread overview]
Message-ID: <ajQ1qvJ-7Lw7GryP@chamomile> (raw)
In-Reply-To: <ajQrwgb0GkKG-utR@strlen.de>
On Thu, Jun 18, 2026 at 07:32:50PM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > > diff --git a/net/netfilter/nf_conntrack_proto_icmp.c b/net/netfilter/nf_conntrack_proto_icmp.c
> > > index 32148a3a8509..0f39cb147c4f 100644
> > > --- a/net/netfilter/nf_conntrack_proto_icmp.c
> > > +++ b/net/netfilter/nf_conntrack_proto_icmp.c
> > > @@ -117,7 +117,8 @@ int nf_conntrack_inet_error(struct nf_conn *tmpl, struct sk_buff *skb,
> > > enum ip_conntrack_dir dir;
> > > struct nf_conn *ct;
> > >
> > > - WARN_ON(skb_nfct(skb));
> > > + if (unlikely(skb_nfct(skb)))
> > > + DEBUG_NET_WARN_ON_ONCE(1);
>
> Should be
> DEBUG_NET_WARN_ON_ONCE(skb_nfct(skb)));
> ?
>
> > nf_conntrack_in
> > [ reset skb->nfct ]
> > nf_conntrack_handle_icmp
> > nf_conntrack_icmpv4_error
> > nf_conntrack_inet_error
> >
> > There is nf_conntrack_inet_error() which performs the ct lookup.
> > There is resolve_normal_ct() too, but these two are coming later.
> >
> > [ ... snippet that resets skb->nfct ... ]
> > unsigned int
> > nf_conntrack_in(struct sk_buff *skb, const struct nf_hook_state *state)
> > {
> > enum ip_conntrack_info ctinfo;
> > struct nf_conn *ct, *tmpl;
> > u_int8_t protonum;
> > int dataoff, ret;
> >
> > tmpl = nf_ct_get(skb, &ctinfo);
> > if (tmpl || ctinfo == IP_CT_UNTRACKED) {
> > /* Previously seen (loopback or untracked)? Ignore. */
> > if ((tmpl && !nf_ct_is_template(tmpl)) ||
> > ctinfo == IP_CT_UNTRACKED)
> > return NF_ACCEPT;
> > skb->_nfct = 0; <--------- this is reset here.
> > }
> > [ end of snippet ]
> >
> > I don't remember to have seen this WARN_ON, so remove it.
>
> I would keep the DEBUG_NET_WARN_ON_ONCE(), else this gives a
> refcount leak.
>
> Or, move it closer to the end:
>
> 191 /* Update skb to refer to this connection */
> HERE.
> 192 nf_ct_set(skb, ct, ctinfo);
> 193 return NF_ACCEPT;
> 194 }
OK, let's keep it around. Thanks.
next prev parent reply other threads:[~2026-06-18 18:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-01 19:30 [PATCH 0/9 nf-next] netfilter: replace raw warnings with Fernando Fernandez Mancera
2026-06-01 19:30 ` [PATCH 1/9 nf-next] netfilter: xtables: use DEBUG_NET_WARN_ON_ONCE in packet and control paths Fernando Fernandez Mancera
2026-06-01 19:30 ` [PATCH 2/9 nf-next] netfilter: nf_tables: " Fernando Fernandez Mancera
2026-06-01 19:30 ` [PATCH 3/9 nf-next] netfilter: nfnetlink: use DEBUG_NET_WARN_ON_ONCE for attribute validation Fernando Fernandez Mancera
2026-06-01 19:30 ` [PATCH 4/9 nf-next] netfilter: conntrack: use DEBUG_NET_WARN_ON_ONCE on packet paths Fernando Fernandez Mancera
2026-06-18 17:11 ` Pablo Neira Ayuso
2026-06-18 17:32 ` Florian Westphal
2026-06-18 18:15 ` Pablo Neira Ayuso [this message]
2026-06-18 20:32 ` Fernando Fernandez Mancera
2026-06-18 20:38 ` Fernando Fernandez Mancera
2026-06-01 19:30 ` [PATCH 5/9 nf-next] netfilter: nat: use DEBUG_NET_WARN_ON_ONCE in core and helper paths Fernando Fernandez Mancera
2026-06-01 19:30 ` [PATCH 6/9 nf-next] netfilter: tproxy: use DEBUG_NET_WARN_ON_ONCE for protocol fallbacks Fernando Fernandez Mancera
2026-06-01 19:30 ` [PATCH 7/9 nf-next] netfilter: bpf: use DEBUG_NET_WARN_ON_ONCE for missing BTF structures Fernando Fernandez Mancera
2026-06-01 19:30 ` [PATCH 8/9 nf-next] netfilter: flowtable: use DEBUG_NET_WARN_ON_ONCE in offload path Fernando Fernandez Mancera
2026-06-01 19:30 ` [PATCH 9/9 nf-next] netfilter: conncount: use DEBUG_NET_WARN_ON_ONCE on reaching count limit Fernando Fernandez Mancera
2026-06-01 19:35 ` [PATCH 0/9 nf-next] netfilter: replace raw warnings with Fernando Fernandez Mancera
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=ajQ1qvJ-7Lw7GryP@chamomile \
--to=pablo@netfilter.org \
--cc=coreteam@netfilter.org \
--cc=fmancera@suse.de \
--cc=fw@strlen.de \
--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.