Messages in this thread | | | Date | Mon, 12 Dec 2011 19:19:14 +0800 | Subject | Re: [PATCH 3/3] kref: Remove the memory barriers | From | Ming Lei <> |
| |
On Mon, Dec 12, 2011 at 7:05 PM, Peter Zijlstra <peterz@infradead.org> wrote: > > 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
Indeed, that is the famous open/disconnect race. In fact, there is the bug in usb-skeleton.c. Suppose usb device is disconnected between usb_get_intfdata() and kref_get() in skel_open(), kref_get may access a freed object.
> 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. > >
thanks, -- Ming Lei
| |