linux-kernel - Re: [PATCH] usb_storage: make usb-stor-scan task non-freezable

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] [day] [month] [year] [list]

Date:	Tue, 26 Jul 2011 10:21:38 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Seth Forshee <seth.forshee@...onical.com>
cc:	Matthew Dharm <mdharm-usb@...-eyed-alien.net>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	<linux-usb@...r.kernel.org>,
	<usb-storage@...ts.one-eyed-alien.net>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] usb_storage: make usb-stor-scan task non-freezable

On Tue, 26 Jul 2011, Seth Forshee wrote:

> On Sat, Jul 23, 2011 at 09:56:15PM -0400, Alan Stern wrote:
> > On Sat, 23 Jul 2011, Seth Forshee wrote:
> > 
> > > After experimenting with this device more I came to the conclusion that
> > > the normal behavior with this machine is for the card reader to be
> > > disconnected from the USB bus unless there's a card in the slot. During
> > > a normal boot with an empty card slot the card reader never shows up on
> > > the bus.
> > 
> > Weird.  Then the reader would never be usable.  Unless it connects 
> > itself to the bus when a card is inserted?
> 
> Yes, the reader is connected to the bus when a card is inserted. Remove
> the card and it disappears again.

That's the first time I've heard of such a thing.

> > > The only solution I've come up with is to leave usb-stor-scan freezable
> > > without allowing it to actually freeze. We can request a fake signal be
> > > sent when freezing and use interruptible sleep to abort the wait early
> > > and finish up the thread's processing. This is implemented in the patch
> > > below. Does this approach look reasonable? It's rather subtle, but it
> > > does seem to work. I done numerous S4 cycles with and without a card
> > > inserted and didn't get any failures.
> > 
> > This runs the risk of failing to suspend if scanning takes too long.  
> 
> It may increase the exposure to that risk, but really the risk is
> already there.

True.  Once the scanning begins there's no way to freeze the thread, 
even in the current code.

> > On the other hand, many systems nowadays use async scanning anyway.
> > And that combination of events isn't too likely to happen, whereas 
> > you're facing a real problem right now.  So I guess this is okay.
> 
> Great, thanks.
> 
> Will the patch get picked up from my previous email, or do I need to
> resend it?

You should resend it to Greg, and you can add

Acked-by: Alan Stern <stern@...land.harvard.edu>

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/