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  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]
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.

Powered by blists - more mailing lists