Messages in this thread | | | Date | Sun, 15 Jun 2003 12:42:26 -0400 (EDT) | From | Alan Stern <> | Subject | Flaw in the driver-model implementation of attributes |
| |
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/
| |