Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 16 Jun 2003 11:38:26 -0700 (PDT) | From | Patrick Mochel <> | Subject | Re: Flaw in the driver-model implementation of attributes |
| |
> I agree. The problem here is that the sysfs/driver-model core is putting > an object into a structure (i.e., a pointer to the device_attribute > structure is being stored in the dentry for a user-owned file) without > taking the corresponding responsibility for the lifetime of the driver > code that the attribute refers to. The struct driver's reference count is > _not_ incremented; in fact device_create_file() doesn't even _have_ a > struct driver argument to say who the caller is.
That's not the problem, only one possible solution. The problem is that the driver does not own the object it's exporting the attribute for.
The object who owns the attributes gets its refcount incremented when the file is opened. If the module owns that object, it can take measures on unload to wait for that reference count to reach 0.
If a piece of code exports an attribute for an object that it does not own, it must explicitly modify the reference count for that object. There is no other way to be safe.
Note that by pinning the driver in memory when you create a sysfs file that it owns will prevent the module from ever being unloaded. That is possible, but not desirable. Note that that change would make your point moot. :)
Also, device_create_file() does not have a driver argument, because drivers are not the only entities that may create files for a device. The owning bus and the core itself may also use that call. Drivers are probably the least qualified (most unsafe) entities to do so.
-pat
- 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/
| ![\](/images/icornerr.gif) |