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@xxxxxxx> > > > > 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@xxxxxxx> > > --- > > 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@xxxxxxxxx/ > 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.
