Messages in this thread |  | | Date | Tue, 9 Feb 2021 20:26:17 +0200 | From | Ido Schimmel <> | Subject | Re: [PATCH v2 net-next 03/11] net: bridge: don't print in br_switchdev_set_port_flag |
| |
On Tue, Feb 09, 2021 at 07:36:31PM +0200, Vladimir Oltean wrote: > On Tue, Feb 09, 2021 at 05:19:28PM +0200, Vladimir Oltean wrote: > > From: Vladimir Oltean <vladimir.oltean@nxp.com> > > > > Currently br_switchdev_set_port_flag has two options for error handling > > and neither is good: > > - The driver returns -EOPNOTSUPP in PRE_BRIDGE_FLAGS if it doesn't > > support offloading that flag, and this gets silently ignored and > > converted to an errno of 0. Nobody does this. > > - The driver returns some other error code, like -EINVAL, in > > PRE_BRIDGE_FLAGS, and br_switchdev_set_port_flag shouts loudly. > > > > The problem is that we'd like to offload some port flags during bridge > > join and leave, but also not have the bridge shout at us if those fail. > > But on the other hand we'd like the user to know that we can't offload > > something when they set that through netlink. And since we can't have > > the driver return -EOPNOTSUPP or -EINVAL depending on whether it's > > called by the user or internally by the bridge, let's just add an extack > > argument to br_switchdev_set_port_flag and propagate it to its callers. > > Then, when we need offloading to really fail silently, this can simply > > be passed a NULL argument. > > > > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> > > --- > > The build fails because since I started working on v2 and until I sent > it, Jakub merged net into net-next which contained this fix: > https://patchwork.kernel.org/project/netdevbpf/patch/20210207194733.1811529-1-olteanv@gmail.com/ > for which I couldn't change prototype due to it missing in net-next. > I think I would like to rather wait to gather some feedback first before > respinning v3, if possible.
It seems that in the sysfs call path br_switchdev_set_port_flag() will be called with the bridge lock held, which is going to be a problem given that patch #8 allows this function to block.
|  |