Thread (28 messages) 28 messages, 8 authors, 2020-12-10

Re: Correct usage of dev_base_lock in 2020

From: Eric Dumazet <hidden>
Date: 2020-11-30 20:19:02


On 11/30/20 8:46 PM, Vladimir Oltean wrote:
On Mon, Nov 30, 2020 at 08:22:01PM +0100, Eric Dumazet wrote:
quoted
And ?

A bonding device can absolutely maintain a private list, ready for
bonding ndo_get_stats() use, regardless
of register/unregister logic.

bond_for_each_slave() is simply a macro, you can replace it by something else.
Also, coming to take the comment at face value.
Can it really? How? Freeing a net_device at unregister time happens
after an RCU grace period.
Except that the device would have to be removed from the bonding list
before the RCU grace period starts.

This removal would acquire the bonding ->stats_mutex in order to change the list.

 So whatever the bonding driver does to keep a
private list of slave devices, those pointers need to be under RCU
protection.

Not at all, if this new list is _only_ used from process context,
and protected by a per-device mutex.

I am not speaking of existing lists that _possibly_ are
used from IRQ context, thus are using RCU.


 And that doesn't help with the sleepable context that we're
looking for.
Again, RCU would not be used at all, since you want ndo_get_stats64()
being called in process context (sleepable context)

And this should be solved without expanding RTNL usage.
(We do not want to block RTNL for ~10ms just because a device driver has to sleep
while a firmware request is processed)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help