Re: [PATCH net] team: postpone features update to avoid deadlock

On Thu, 21 Jan 2021 11:29:37 +0100 Ivan Vecera wrote:

On Wed, 20 Jan 2021 15:18:20 -0800
Cong Wang [off-list ref] wrote:

quoted

On Wed, Jan 20, 2021 at 4:56 AM Ivan Vecera [off-list ref] wrote:  

quoted

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.

quoted

quoted

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.