lkml.org 
[lkml]   [2011]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 3/3] kref: Remove the memory barriers
From
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


\
 
 \ /
  Last update: 2011-12-12 12:21    [W:0.065 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site