lkml.org 
[lkml]   [2003]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectFlaw 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/

    \
     
     \ /
      Last update: 2005-03-22 13:36    [W:2.651 / U:0.100 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site