Re: [PATCH 36/78] USB: add power/level sysfs attribute

Alan Stern <[email protected]>
Newsgroups gmane.linux.usb.devel
Message-ID <[email protected]>
On Fri, 27 Apr 2007, Oliver Neukum wrote:

> Am Freitag, 27. April 2007 20:55 schrieb Greg Kroah-Hartman:
> > +       } else if (len == sizeof suspend_string - 1 &&
> > +                       strncmp(buf, suspend_string, len) == 0) {
> > +               udev->autosuspend_disabled = 0;
> > +               udev->autoresume_disabled = 1;
> > +               rc = usb_external_suspend_device(udev, PMSG_SUSPEND);
> > +
> 
> Hi,
> 
> this introduces the possibility of a suspension while user space is
> doing IO.

In other words, one user can force a device to suspend while another user 
is trying to access the device.  True enough.  The second user will get 
I/O errors.

This is why sysfs files need write-access restrictions.

> Now I know that I was in favor of doing this. But on second
> thought, it is problematic. It seems to me we should have a way
> to generically block io. This is not solvable in the suspend method,
> as we can't tell this apart from STR. We'd need locks between
> suspend and all io methods.
> 
> What's to be done?

Why bother to block I/O?  Let it fail.  It's no worse than what happens 
when you unplug a USB device.

In general, I/O shouldn't be blocked at the device driver level.  It 
should be blocked higher up, in a class device or an I/O queue manager -- 
if it is to be blocked at all.

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.