Am Freitag, 24. November 2006 21:55 schrieb Alan Stern:
> On Fri, 24 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.
> > 
> > That's bad.
> 
> It isn't good.  On the other hand, if the attribute's permissions make it 
> inaccessible to everybody except root then the problem isn't so bad.

That's a significant reduction of utility.

> > In fact I don't trust the semantics of device_remove_file(), but even if it
> > has the semantics here assumed the driver is still buggy and therefore
> > I fixed it.
> > 
> > Wild idea: How about setting struct subsys_attribute * to NULL and react in
> > fill_read_buffer() ?
> 
> That won't work for two reasons.  First, there's still a race.  Second, it
> doesn't solve the problem of what happens when there are two transvibrator
> devices and one gets unplugged.

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)

        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