linux-kernel - Re: USB device cannot be reconnected and khubd "blocked for more than 120 seconds"

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.1301121748360.4723-100000@netrider.rowland.org>
Date:	Sat, 12 Jan 2013 17:52:16 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Alex Riesen <raa.lkml@...il.com>
cc:	linux-usb@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: USB device cannot be reconnected and khubd "blocked for more
 than 120 seconds"

On Sat, 12 Jan 2013, Alex Riesen wrote:

> On Sat, Jan 12, 2013 at 8:39 PM, Alex Riesen <raa.lkml@...il.com> wrote:
> > On Sat, Jan 12, 2013 at 6:37 PM, Alan Stern <stern@...land.harvard.edu> wrote:
> >> On Sat, 12 Jan 2013, Alex Riesen wrote:
> >>> One more detail: I usually use the "noop" elevator. That time it was
> >>> the "deadline". And I just reproduced it easily with "deadline".
> >>
> >> I doubt the elevator has anything to do with this.
> >
> > But it looks like it does: just using the deadline elevator is a sure way
> > to reproduce the bug. The system always recovers (sometimes after a while)
> > with "noop".
> 
> And no, it does not. Not by itself, but the fact that deadline elevator was
> compiled as module certainly helped!
> 
> This explains the hanging modprobe in the dmesg output (the part after device
> connect). I still wonder, why didn't it froze at boot, mounting SATA devices
> (the root, /var, and /home are on an SSD connected by SATA)? And why hanging
> khubd at reboot?
> 
> Anyway, building the elevator in the kernel avoids the problem. Sorry for
> not spotting this earlier.
> 
> Now, who would be interested to handle this kind of misconfiguration ...

So the whole thing was a false alarm?

Maybe you should report to the block-layer maintainers that it's 
possible to mess up the system by building an elevator as a module.  
That sounds like the sort of thing they'd be interested to hear.

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/