linux-kernel - Re: Status of storage autosuspend

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.0802181530330.31135-100000@netrider.rowland.org>
Date:	Mon, 18 Feb 2008 15:36:17 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Pavel Machek <pavel@....cz>
cc:	kernel list <linux-kernel@...r.kernel.org>,
	Linux-pm mailing list <linux-pm@...ts.osdl.org>
Subject: Re: Status of storage autosuspend

On Mon, 18 Feb 2008, Pavel Machek wrote:

> Hi!
> 
> What is the status of USB storage/SCSI autosuspend patches? They work
> nicely here ;-).

I could submit them, but there is one outstanding problem I would like
to solve first.  Maybe you can suggest a solution.

The problem is how to handle SG_IOCTL calls.  It seems that the only
safe thing to do is to force an autoresume and prevent the device from
autosuspending until the device file is closed.  Unfortunately the
SG_IOCTL stuff is all handled inside the block layer, and there's no
apparent way (other than some dreadful hack) of passing the necessary
information down to the SCSI layer.

Should we ignore this issue and submit the patches anyway?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/