netdev - Re: [PATCH v2 net 5/6] net: enetc: don't disable VLAN filtering in IFF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210226164519.4da3775d@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Fri, 26 Feb 2021 16:45:19 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     "David S . Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        Michael Walle <michael@...le.cc>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Alexandru Marginean <alexandru.marginean@....com>,
        Vladimir Oltean <vladimir.oltean@....com>,
        Markus Blöchl <Markus.Bloechl@...tronik.com>
Subject: Re: [PATCH v2 net 5/6] net: enetc: don't disable VLAN filtering in
 IFF_PROMISC mode

On Sat, 27 Feb 2021 02:16:51 +0200 Vladimir Oltean wrote:
> On Fri, Feb 26, 2021 at 03:49:22PM -0800, Jakub Kicinski wrote:
> > On Sat, 27 Feb 2021 01:42:44 +0200 Vladimir Oltean wrote:  
> > > What I'm fixing is unexpected behavior, according to the applicable
> > > standards I could find. If I don't mark this change as a bug fix but as
> > > a simple patch, somebody could claim it's a regression, since promiscuity
> > > used to be enough to see packets with unknown VLANs, and now it no
> > > longer is...  
> >
> > Can we take it into net-next? What's your feeling on that option?  
> 
> I see how you can view this patch as pointless, but there is some
> context to it. It isn't just for tcpdump/debugging, instead NXP has some
> TSN use cases which involve some asymmetric tc-vlan rules, which is how
> I arrived at this topic in the first place. I've already established
> that tc-vlan only works with ethtool -K eth0 rx-vlan-filter off:
> https://lore.kernel.org/netdev/CA+h21hoxwRdhq4y+w8Kwgm74d4cA0xLeiHTrmT-VpSaM7obhkg@mail.gmail.com/
> and that's what we recommend doing, but while adding the support for
> rx-vlan-filter in enetc I accidentally created another possibility for
> this to work on enetc, by turning IFF_PROMISC on. This is not portable,
> so if somebody develops a solution based on that in parallel, it will
> most certainly break on other non-enetc drivers.
> NXP has not released a kernel based on the v5.10 stable yet, so there is
> still time to change the behavior, but if this goes in through net-next,
> the apparent regression will only be visible when the next LTS comes
> around (whatever the number of that might be). Now, I'm going to
> backport this to the NXP v5.10 anyway, so that's not an issue, but there
> will still be the mild annoyance that the upstream v5.10 will behave
> differently in this regard compared to the NXP v5.10, which is again a
> point of potential confusion, but that seems to be out of my control.
> 
> So if you're still "yeah, don't care", then I guess I'm ok with leaving
> things alone on stable kernels.

I see, so this is indeed of practical importance to NXP.

Would you mind re-spinning with an expanded justification?