On 31.01.2019 18:21, Eric Dumazet wrote: > > > On 01/31/2019 07:15 AM, Eric Dumazet wrote: >> >> >> On 01/31/2019 05:49 AM, Kirill Tkhai wrote: >>> >>> 2)Not related to your patch -- it looks like we have problem in existing >>> code with this netdev_refcnt_read(). It does not imply a memory ordering >>> or some guarantees about reading percpu values. For example, in generic >>> code struct percpu_ref switches a counter into atomic mode before it checks >>> for the last reference. But there is nothing in netdev_refcnt_read(). >> >> Well, if we read an old value here, after a full and expensive >> synchronize_net(), >> then we would have lot more problems than simply having a second round in >> netdev_wait_allrefs() >> >> > > percpu_ref was added more recently than the netdev_refcnt stuff, and is > interesting for users wanting a synchronous wait for the refcnt reaching 0. > > netdev_wait_allrefs() was designed to be asynchronous, so that we at least > release > RTNL (and current cpu) when something is wrong and a device can not be > dismantled.
Yeah, they are different, and I think we can't add more synchronize_rcu()-dependent synchronizations in this code, since network namespaces are already destroyed very slow.
