Date: Sun, 15 Jun 2003 12:42:26 -0400 (EDT)
From: Alan Stern <stern@rowland.harvard.edu>
To: Greg KH <greg@kroah.com>, Patrick Mochel <mochel@osdl.org>
cc: linux-kernel@vger.kernel.org
Subject: Flaw in the driver-model implementation of attributes
Message-ID: <Pine.LNX.4.44L0.0306151221190.32270-100000@netrider.rowland.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1669
Lines: 32

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/