On Tue, Jun 17, 2008 at 03:41:00PM -0700, Joel Becker wrote: > configfs_mkdir() creates a new item by calling its parent's > ->make_item/group() functions. Once that object is created, > configfs_mkdir() calls try_module_get() on the new item's module. If it > succeeds, the module owning the new item cannot be unloaded, and > configfs is safe to reference the item. > > If the item and the subsystem it belongs to are part of the same module, > the subsystem is also pinned. This is the common case. > > However, if the subsystem is made up of multiple modules, this may not > pin the subsystem. Thus, it would be possible to unload the toplevel > subsystem module while there is still a child item. Thus, we now > try_module_get() the subsystem's module. This only really affects > children of the toplevel subsystem group. Deeper children already have > their parents pinned. Looks good to me. What about new item module pinning versus a concurrent sys_delete_module() in a preemptible kernel? AFAICS new_item pinning is just done too late to protect anybody against sys_delete_module(). Shouldn't we remove new item module pinning and let the subsystem do it? process 1: process 2: confifs_mkdir() item = make_item() --- preemption schedule --- sys_delete_module() ok --- end of preemption --- new_item_owner = item->ci_type.ct_owner Possible access to freed memory if type statically allocated! try_module_get(new_item_owner) Access to freed memory of the module metadata! Louis -- Dr Louis Rilling Kerlabs Skype: louis.rilling Batiment Germanium Phone: (+33|0) 6 80 89 08 23 80 avenue des Buttes de Coesmes http://www.kerlabs.com/ 35700 Rennes
Attachment:
signature.asc
Description: Digital signature
