lkml.org 
[lkml]   [2007]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: refcounting drivers' data structures used in sysfs buffers
On Fri, 9 Mar 2007, Alan Stern wrote:

> Oliver, your idea won't work either. Think about what would happen if
> someone did
>
> rmmod driver_module </sys/devices/.../attribute_file
>
> The rmmod process would never actually read the attribute, so until it
> exited the private data structure would have a positive refcount. But
> rmmod can't exit until the driver has been unloaded from memory, and it
> can't be unloaded while its data structure is still allocated. Thus we
> would end up with deadlock; rmmod would hang forever.

I take this back. Redirecting stdin to the attribute file would increase
the module's refcount and cause rmmod to exit immediately with an error.

After some more thought, I basically agree with what Oliver wrote
originally. sysfs_dirent is indeed the logical place to store the kref
pointer. However it needs to be used during open and release, not during
read, write, and poll. Another point, which Oliver didn't think of, is
that the kref pointer needs to be passed to the driver as an argument in
the show() and store() method calls.

Implementing this will be difficult. One possibility is to change the
definition of sysfs_ops, adding the new struct kref * argument to the
prototypes. This will involve changing _lots_ of source files, adding an
unused argument to many functions, which isn't attractive.

The other possibility is to test at runtime whether the kref pointer is
NULL, and if it is, don't pass it. This would work, but it isn't
type-safe.

Finally, there's added complexity in each driver which wants to use the
new facility. The module_exit routine will need to be smart enough to
block until all the private data structures have been released.
usb-storage does something like that now; it's kind of ugly (although it
could be improved if appropriate support were added to the core kernel).

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-03-09 21:11    [W:0.126 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site