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]
Date:   Mon, 14 Feb 2022 12:27:57 +0200
From:   Nikolay Aleksandrov <nikolay@...dia.com>
To:     Vladimir Oltean <vladimir.oltean@....com>,
        Ido Schimmel <idosch@...sch.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        Roopa Prabhu <roopa@...dia.com>, Jiri Pirko <jiri@...dia.com>,
        Ido Schimmel <idosch@...dia.com>,
        Rafael Richter <rafael.richter@....de>,
        Daniel Klauer <daniel.klauer@....de>,
        Tobias Waldekranz <tobias@...dekranz.com>
Subject: Re: [RFC PATCH net-next 0/5] Replay and offload host VLAN entries in
 DSA

On 14/02/2022 12:07, Vladimir Oltean wrote:
> On Mon, Feb 14, 2022 at 11:59:02AM +0200, Ido Schimmel wrote:
>> Sounds good to me as well. I assume it means patches #1 and #2 will be
>> changed to make use of this flag and patch #3 will be dropped?
> 
> Not quite. Patches 1 and 2 will be kept as-is, since fundamentally,
> their goal is to eliminate a useless SWITCHDEV_PORT_OBJ_ADD event when
> really nothing has changed (flags == old_flags, no brentry was created).
> 

I don't think that's needed, a two-line change like
"vlan_already_exists == true && old_flags == flags then do nothing"
would do the trick in DSA for all drivers and avoid the churn of these patches.
It will also keep the order of the events consistent with (most of) the rest
of the bridge. I'd prefer the simpler change which avoids config reverts than
these two patches.

> Patch 3 will be replaced with another patch that extends
> br_switchdev_port_vlan_add() and struct switchdev_obj_port_vlan with a
> "bool changed" meaning that "this notification signifies a change of
> flags for an existing VLAN", and the callers of br_switchdev_port_vlan_add()
> will populate it with false, or *changed, or *flags_changed, as appropriate.

Thanks,
 Nik

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ