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
| ||
|
Date: Tue, 12 Feb 2019 13:14:47 +0000 From: Ido Schimmel <idosch@...lanox.com> To: Florian Fainelli <f.fainelli@...il.com> CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "David S. Miller" <davem@...emloft.net>, open list <linux-kernel@...r.kernel.org>, "open list:STAGING SUBSYSTEM" <devel@...verdev.osuosl.org>, "moderated list:ETHERNET BRIDGE" <bridge@...ts.linux-foundation.org>, Jiri Pirko <jiri@...lanox.com>, "andrew@...n.ch" <andrew@...n.ch>, "vivien.didelot@...il.com" <vivien.didelot@...il.com> Subject: Re: [PATCH net-next v4 0/9] net: Remove switchdev_ops On Mon, Feb 11, 2019 at 11:09:52AM -0800, Florian Fainelli wrote: > Hi all, > > This patch series finishes by the removal of switchdev_ops. To get there > we convert the existing switchdev_port_attr_{set,get} switchdev_ops to > use a blocking notifier, thus making it consistent with how the objects > are pushed to the switchdev enabled devices. > > Please review and let me know what you think! > > David, I would like to get Ido's feedback on this to make sure I did not > miss something, thank you! Hi Florian, Why do you still keep switchdev_port_attr_get()? I believe we can remove it and simplify things. After your recent patchset to remove 'PORT_BRIDGE_FLAGS', the only remaining user of get() is 'PORT_BRIDGE_FLAGS_SUPPORT'. It can be converted to a blocking set() with 'PORT_PRE_BRIDGE_FLAGS' (or a similar name). I would like to make sure we're in sync with regards to future changes. After this patchset to get rid of switchdev_ops we can continue to completely removing switchdev (I believe Jiri approves). The prepare-commit model is not really needed and the two switchdev notification chains can be split into bridge and vxlan specific chains. Notifications sent in an atomic context can be handled by drivers directly in this context. Similar to how FDB/route/neighbour are handled. It will really simplify things. No need for the defer flag anymore and tricks like 'PORT_BRIDGE_FLAGS_SUPPORT' and 'PORT_PRE_BRIDGE_FLAGS'. In the atomic context the driver can veto the requested bridge flags, but program the device from a blocking context (using a workqueue).
Powered by blists - more mailing lists