Messages in this thread | | | Subject | Re: [PATCH 3/3] kref: Remove the memory barriers | From | Peter Zijlstra <> | Date | Mon, 12 Dec 2011 12:05:48 +0100 |
| |
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.
| |