> On Mon, Jun 16, 2003 at 01:54:34PM -0400, Alan Stern wrote:
> > That's not practical. How else can a device driver provide
> > device-specific configuration options or information in sysfs? In many
> > cases the device is owned by the bus, not the device driver.
> Practical or not, when you put sysfs object into a structure, you take
> full responsibility for the lifetime of that structure. Period.
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.
You could make a good case that this ought to be fixed by changing either
the sysfs or the driver model code. But in either case, the fault lies in
the core implementation, not in the driver.
> Note that problems exist even when kernel is non-modular. Even if code
> stays in place, the data getting freed under you is just as bad. And
> that can trivially happen without any modules.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/