On Thu, 21 Jan 2021 11:29:37 +0100 Ivan Vecera wrote: > On Wed, 20 Jan 2021 15:18:20 -0800 > Cong Wang <xiyou.wangc...@gmail.com> wrote: > > On Wed, Jan 20, 2021 at 4:56 AM Ivan Vecera <ivec...@redhat.com> wrote: > > > Team driver protects port list traversal by its team->lock mutex > > > in functions like team_change_mtu(), team_set_rx_mode(),
The set_rx_mode part can't be true, set_rx_mode can't sleep and team->lock is a mutex. > > > To fix the problem __team_compute_features() needs to be postponed > > > for these cases. > > > > Is there any user-visible effect after deferring this feature change? > > An user should not notice this change. I think Cong is right, can you expand a little on your assertion? User should be able to assume that the moment syscall returns the features had settled. What does team->mutex actually protect in team_compute_features()? All callers seem to hold RTNL at a quick glance. This is a bit of a long shot but isn't it just tryin to protect the iteration over ports which could be under RCU? More crude idea would be to wrap the mutex_unlock(&team->lock) into a helper which checks if something tried to change features while it was locked. rtnl_unlock()-style.
