Re: Flaw in the driver-model implementation of attributes

Patrick Mochel (mochel@osdl.org)
Mon, 16 Jun 2003 11:38:26 -0700 (PDT)


> 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/