If you're already aware of this, please forgive the intrusion.
There's a general problem in the driver model's implementation of
attribute files, in connection with loadable kernel modules. The
sysfs_ops structure stores function pointers with no means for identifying
the module that contains the corresponding code. As a result, it's
possible to call through one of these pointers even after the module has
been unloaded, causing an oops.
It's not hard to provoke this sort of situation. A user process can
open a sysfs device file, for instance, and delay trying to read it until
the module containing the device driver has been removed. When the read
does occur, it runs into trouble.
I don't know enough about the innards of the system to be able to fix this
properly. One possible approach works like this. Modify fs/sysfs/file.c
to make fill_read_buffer() and flush_write_buffer() acquire some sort of
read lock on file->f_dentry before they set attr =
file->f_dentry->d_fsdata. Modify sysfs_remove_file() to acquire a write
lock and have it set file->f_dentry->d_fsdata to NULL. Then it will only
be necessary to avoid calling ops->show() or ops->store() if attr is NULL.
This guarantees that no caller will execute the show() or store() methods
after syfs_remove_file() has returned, so a driver that cleans up after
itself correctly will not be invoked after it has been unloaded.
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/
This archive was generated by hypermail 2b29 : Sun Jun 15 2003 - 22:00:42 EST