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: <20110726133317.GB6687@thinkpad-t410>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ