Re: [PATCH 3/3] kref: Remove the memory barriers

[Peter Zijlstra <peterz@infradead.org>]

On Mon, 2011-12-12 at 18:32 +0800, Ming Lei wrote:
> On Mon, Dec 12, 2011 at 6:12 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > I don't know the driver model, and I don't plan to start learning it
> > now. But if what you said is possible its broken and no memory barriers
> > will fix it.
> 
> IMO, you don't need to learn it, and my example is very simple and common
> kref usage in device drivers, :-)

One needs to know the callchains and device driver core code leading up
to those .open, .close, .read, .probe and .release callbacks. That's a
lot of code.

Also, non of that is relevant. The kref interface is very simple.
kref_set cannot and should not have any concurrency.

It it not for kref_set() to finalize the object (there is no requirement
kref_set is the last operation before you publish the object).

As per Oliver's reply, your USB example uses usb_register_dev() to
pushlish the object and that includes the LOCK and UNLOCK from my
example; it also illustrates you do need to know the entire device model
in order to talk sensibly about these callbacks you mentioned.

You already said that external means should be used to ensure no
kref_get() is issued after the final kref_put(). This too is only
possible if you use locks one way or another and I bet that if you go
look at the device model you'll find plenty around device_unregister().

These two constraints alone are enough to remove both memory barriers
from the kref code.