From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Florian Westphal <fw@strlen.de>
Cc: netdev@vger.kernel.org, Paolo Abeni <pabeni@redhat.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
netfilter-devel@vger.kernel.org
Subject: Re: [PATCH net 0/4] netfilter: updates for net
Date: Thu, 5 Mar 2026 10:40:14 +0100 [thread overview]
Message-ID: <aalPfgw5Ypsik8NY@chamomile> (raw)
In-Reply-To: <aalHS6-11HUHy-Dd@strlen.de>
On Thu, Mar 05, 2026 at 10:05:15AM +0100, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > Hi Florian,
> >
> > On Wed, Mar 04, 2026 at 06:29:36PM +0100, Florian Westphal wrote:
> > > Hi,
> > >
> > > The following patchset contains Netfilter fixes for *net*:
> > >
> > > 1) Fix a bug with vlan headers in the flowtable infrastructure.
> > > Existing code uses skb_vlan_push() helper, but that helper
> > > requires skb->data to point to the MAC header, which isn't the
> > > case for flowtables. Switch to a new helper, modeled on the
> > > existing PPPoE helper. From Eric Woudstra. This bug was added
> > > in v6.19-rc1.
> >
> > In patch 1/4, why is this new function so different wrt. skb_vlan_push?
> >
>
> I asked that to Eric when I reviewed this, and that was his reply:
> --------------------------------------------------------------------
> The code here for the inner header is an almost exact copy of
> nf_flow_pppoe_push(), which was also implemented at the same time.
> So handling pppoe and inner-vlan header is implemented in the same
> manner, which keeps it simple and uniform. If one functions
> (in)correctly, then so would the other.
>
> I've been implementing handling the inner vlan header like this for a
> half year now. My version of nf_flow_encap_push() was a bit different,
> but after this patch it is quite similar.
> --------------------------------------------------------------------
>
> > skb_postpush_rcsum(skb, skb->data + (2 * ETH_ALEN), VLAN_HLEN);
> > }
> > __vlan_hwaccel_put_tag(skb, vlan_proto, vlan_tci);
> >
> >
> > In case there are two VLANs, the existing in hwaccel gets pushed into
> > the VLAN header, and the outer VLAN becomes the one that is offloaded?
> >
> > Is this reversed in this patch? The first VLAN tag is offloaded, then
> > the next one coming is pushed as a VLAN header?
>
> Yes, it looks broken. I wonder why we have no tests for this stuff.
> First a vlan push function that cannot have worked, ever, now this
> seemingly reversing-headers variant:
This used to work, I just accidentally broke it when using
skb_vlan_push() in net-next.
I will post fix.
> For PPPOE, its pushing the ppppe header to packet, so we get
> strict ordering, later header coming in the stack gets placed on
> top, before older one.
>
> Here, first vlan push gets placed into hw tag in skb (which makes
> sense, let HW take care of it).
>
> But if 2nd comes along, then that gets placed in the packet
> and the hwaccel tag remains?
>
> What to do? Should be nuke vlan offload support from flowtable?
> It appears to be an unused feature.
>
> I have low confidence in this code.
Could you elaborate more precisely?
Thanks.
next prev parent reply other threads:[~2026-03-05 9:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-04 17:29 [PATCH net 0/4] netfilter: updates for net Florian Westphal
2026-03-04 17:29 ` [PATCH net 1/4] netfilter: nf_flow_table_ip: Introduce nf_flow_vlan_push() Florian Westphal
2026-03-04 17:29 ` [PATCH net 2/4] netfilter: nf_tables: unconditionally bump set->nelems before insertion Florian Westphal
2026-03-04 17:29 ` [PATCH net 3/4] netfilter: nf_tables: clone set on flush only Florian Westphal
2026-03-04 17:29 ` [PATCH net 4/4] netfilter: nft_set_pipapo: split gc into unlink and reclaim phase Florian Westphal
2026-03-04 21:57 ` [PATCH net 0/4] netfilter: updates for net Pablo Neira Ayuso
2026-03-05 9:05 ` Florian Westphal
2026-03-05 9:40 ` Pablo Neira Ayuso [this message]
2026-03-05 12:20 ` Florian Westphal
2026-03-05 12:21 ` Florian Westphal
-- strict thread matches above, loose matches on Subject: below --
2025-12-10 11:07 Florian Westphal
2025-10-08 12:59 Florian Westphal
2023-10-18 12:55 Florian Westphal
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=aalPfgw5Ypsik8NY@chamomile \
--to=pablo@netfilter.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fw@strlen.de \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pabeni@redhat.com \
/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.