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]

Date:	Sun, 13 Jan 2013 21:39:34 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Oliver Neukum <oliver@...kum.org>
cc:	Alex Riesen <raa.lkml@...il.com>, Jens Axboe <axboe@...nel.dk>,
	<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 Sun, 13 Jan 2013, Oliver Neukum wrote:

> On Sunday 13 January 2013 18:42:49 Alex Riesen wrote:
> > On Sun, Jan 13, 2013 at 5:56 PM, Alan Stern <stern@...land.harvard.edu> wrote:
> > > On Sun, 13 Jan 2013, Alex Riesen wrote:
> > >>
> > >> Yes, almost. What about khubd hanging when machine is shutdown?
> > >
> > > What about it?  I have trouble understanding all the descriptions you
> > > have provided so far, because you talk about several different things
> > > and change your mind a lot.  Can you provide a single, simple scenario
> > > that illustrates this problem?
> > 
> > 1. Compile a kernel with deadline elevator as module
> > 2. Boot into it, make sure the elevator is selected
> >   (I used "elevator=deadline" in the kernel command line)
> > 3. Insert a FAT formatted mass storage device in an USB2 port
> >    Observe "io scheduler deadline registered"
> > 4. Pull the stick out, wait a moment, and either shutdown or just
> >    and press alt-sysrq-W:

Indeed.  I just tried booting into a kernel that has the deadline
elevator built-in, not a module.  Even then, when I specified
"elevator=deadline" on the boot command line, the system hung up
partway through booting.  Hard to tell exactly where, because it
occurred shortly after the switching from VGA to the framebuffer
driver, so the screen was completely blank.

When I get a chance, I'll try it on another machine where I can use a 
serial console.

> That makes it clear. The elevator probably has scheduled work
> which cannot finish waiting on a lock and scsi_remove_host()
> wants to flush work.

What is the work and why can't it finish?  Or rather, how can we 
figure these things out?  According to what Alex wrote, the blocked 
task doesn't show up in the Alt-SysRq-W listing.

And don't forget that the listing shows scsi_remove_host() blocks
waiting to acquire the host's scan_mutex.  Not waiting for work to be
flushed.  This casts doubt on your explanation.

> This is not a USB problem. You need to involve the SCSI people.
> khubd just stops working because disconnects are processed
> in its context and the removal deadlocks.

The why whould building the deadline elevator as a module make any
difference?  Or does it make a difference?

Alex, if the elevator is made static instead, do you still see the same 
behavior when the USB drive is removed?

Also, are there any mounted filesystems on the drive when you unplug
it?

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/