netdev - Re: [PATCH net-next] net: dsa: propagate switchdev vlan

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 for Android: free password hash cracker in your pocket

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

Message-Id: <20201005.060552.685538059223511166.davem@davemloft.net>
Date:   Mon, 05 Oct 2020 06:05:52 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     vladimir.oltean@....com
Cc:     netdev@...r.kernel.org, kuba@...nel.org, f.fainelli@...il.com,
        martin.blumenstingl@...glemail.com, hauke@...ke-m.de,
        woojung.huh@...rochip.com, UNGLinuxDriver@...rochip.com,
        sean.wang@...iatek.com, Landen.Chao@...iatek.com, andrew@...n.ch,
        vivien.didelot@...il.com, noodles@...th.li,
        linus.walleij@...aro.org, alexandre.belloni@...tlin.com,
        claudiu.manoil@....com
Subject: Re: [PATCH net-next] net: dsa: propagate switchdev vlan_filtering
 prepare phase to drivers

From: Vladimir Oltean <vladimir.oltean@....com>
Date: Sat,  3 Oct 2020 01:06:46 +0300

> A driver may refuse to enable VLAN filtering for any reason beyond what
> the DSA framework cares about, such as:
> - having tc-flower rules that rely on the switch being VLAN-aware
> - the particular switch does not support VLAN, even if the driver does
>   (the DSA framework just checks for the presence of the .port_vlan_add
>   and .port_vlan_del pointers)
> - simply not supporting this configuration to be toggled at runtime
> 
> Currently, when a driver rejects a configuration it cannot support, it
> does this from the commit phase, which triggers various warnings in
> switchdev.
> 
> So propagate the prepare phase to drivers, to give them the ability to
> refuse invalid configurations cleanly and avoid the warnings.
> 
> Since we need to modify all function prototypes and check for the
> prepare phase from within the drivers, take that opportunity and move
> the existing driver restrictions within the prepare phase where that is
> possible and easy.
 ...
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>

Applied, thanks.