Flaw in the driver-model implementation of attributes

[Alan Stern]

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