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
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
