netdev - Re: [PATCH net-next 3/6] net: dsa: Delete the VID from the upstream port as well

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: <CA+h21hodsDTwPHY1pxQA-ucu6FU7rkOQa7Y4HJGZC0fRd8zmDA@mail.gmail.com>
Date:   Wed, 21 Aug 2019 01:09:39 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Vivien Didelot <vivien.didelot@...il.com>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>, Ido Schimmel <idosch@...sch.org>,
        Roopa Prabhu <roopa@...ulusnetworks.com>,
        nikolay@...ulusnetworks.com,
        "David S. Miller" <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 3/6] net: dsa: Delete the VID from the upstream
 port as well

On Wed, 21 Aug 2019 at 00:36, Vivien Didelot <vivien.didelot@...il.com> wrote:
>
> On Wed, 21 Aug 2019 00:02:22 +0300, Vladimir Oltean <olteanv@...il.com> wrote:
> > On Tue, 20 Aug 2019 at 23:58, Vivien Didelot <vivien.didelot@...il.com> wrote:
> > >
> > > On Tue, 20 Aug 2019 23:40:34 +0300, Vladimir Oltean <olteanv@...il.com> wrote:
> > > > I don't need this patch. I'm not sure what my thought process was at
> > > > the time I added it to the patchset.
> > > > I'm still interested in getting rid of the vlan bitmap through other
> > > > means (picking up your old changeset). Could you take a look at my
> > > > questions in that thread? I'm not sure I understand what the user
> > > > interaction is supposed to look like for configuring CPU/DSA ports.
> > >
> > > What do you mean by getting rid of the vlan bitmap? What do you need exactly?
> >
> > It would be nice to configure the VLAN attributes of the CPU port in
> > another way than the implicit way it is done currently. I don't have a
> > specific use case right now.
>
> So you mean you need a lower level API to configure VLANs on a per-port basis,
> without any logic, like including CPU and DSA links, etc.
>
> The bitmap operations were introduced to simplify the switch drivers in the
> future, since most of them could implement the VLAN operations (add, del)
> in simple functions taking all local members at once.
>
> But the Linux interface being exclusively based on a per port (slave) logic,
> it is hard to implement right now.
>
> The thing is that CPU ports, as well as DSA links in a multi-chip setup,
> need to be programmed transparently when a given user port is configured,
> hence the notification sent by a port to all switches of the fabric.
>
> So I'm not against removing the bitmap logic, actually I'm looking into it
> as well as moving more bridge checking logic into the slave code itself,
> because I'm not a fan of your "Allow proper internal use of VLANs" patch.
>
> But you'll need to provide more than "it would be nice" to push in that
> direction, instead of making changes everywhere to make your switch work.
>
>
> Thanks,
>
>         Vivien

I mean I made an argument already for the hack in 4/6 ("Don't program
the VLAN as pvid on the upstream port"). If the hack gets accepted
like that, I have no further need of any change in the implicit VLAN
configuration. But it's still a hack, so in that sense it would be
nicer to not need it and have a better amount of control.