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

Date:	Tue, 26 Jul 2011 08:33:17 -0500
From:	Seth Forshee <seth.forshee@...onical.com>
To:	Alan Stern <stern@...land.harvard.edu>
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 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.

> > 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.

> 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?

Thanks,
Seth
--
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/