public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Pablo Neira Ayuso <pablo@netfilter.org>
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:05:15 +0100	[thread overview]
Message-ID: <aalHS6-11HUHy-Dd@strlen.de> (raw)
In-Reply-To: <aaiqrFrus1syOmlT@chamomile>

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:

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.

  reply	other threads:[~2026-03-05  9:05 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 [this message]
2026-03-05  9:40     ` Pablo Neira Ayuso
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=aalHS6-11HUHy-Dd@strlen.de \
    --to=fw@strlen.de \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pablo@netfilter.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox