Am Samstag, 25. November 2006 03:54 schrieb Alan Stern:
> On Sat, 25 Nov 2006, Oliver Neukum wrote:
> 
> > > > > By the way, you should be aware that creating an attribute file in 
> > > > > the 
> > > > > interface's device directory (like dev_attr_speed above) is 
> > > > > inherently 
> > > > > unsafe.  A user process can open the file, hold it open while the 
> > > > > driver 
> > > > > is unloaded, and then try to read or write it -- causing an oops.
> 
> > OK, a bit more elaborate.
> > 
> > 1. add a list to struct attribute
> > 2. add any struct sysfs_buffer opened to that list
> > 3. in class_device_remove_file walk this list and mark all buffers on a 
> > list orphaned
> > 4. in fill_read_buffer check this flag an fail if need (the operation is 
> > already under lock)
> 
> Actually, I think that might work.  You'd have to add a pointer from
> the sysfs_buffer to the struct file or the dentry, so that you could tell
> which buffers belonged to the device whose file was being removed.  And

Yes, there needs to be a back pointer for close(), but why not to
struct attribute?

> you'd have to synchronize walking the list with opening & closing
> attribute files, which could turn out to be prohibitively difficult.

Not trivial. It seems to me that a simple locking scheme would deadlock.
How about refcounting struct attribute? It would mean that they could not
be allocated statically, but it would solve the problem cleanly and there'd
still be an upper bound on memory consumption due to the limit on open
files.

        Regards
                Oliver

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to