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: <20130116173703.GR2668@htj.dyndns.org>
Date:	Wed, 16 Jan 2013 09:37:03 -0800
From:	Tejun Heo <tj@...nel.org>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Arjan van de Ven <arjan@...ux.intel.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ming Lei <ming.lei@...onical.com>,
	Alex Riesen <raa.lkml@...il.com>, Jens Axboe <axboe@...nel.dk>,
	USB list <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"

Hello, Alan.

On Wed, Jan 16, 2013 at 12:01:53PM -0500, Alan Stern wrote:
> > The problem here is that "flush everything which comes before me" is
> > used to order async jobs.  e.g. after async jobs probe the hardware
> > they order themselves by flushing before registering them, so unless
> 
> I don't fully understand this example.  What is the point -- to make 
> sure that asynchronously probed devices are registered in the order of 
> their discovery?

People still want devices to be numbered to their physical ports and
so on, so we keep the registeration order the same as natural
(whatever that means) hardware order.

> If so, here's how to do it safely: Start up the async jobs in reverse
> order of discovery.  Have each job acquire a cookie when it starts.  
> Then each job needs to wait only for tasks that started after its
> cookie was issued.

It's a bit clumsy but yeah I guess it could work.

> > There aren't too many which use async anyway so changing stuff
> > shouldn't be too difficult but I think the simpicity or dumbness is
> > one of major attractions of async, so it'd be nice to keep things that
> > way and the PF_USED_ASYNC hack seems to be able to hold things
> > together for now.
> 
> Nesting won't matter for the chronological approach.  I really think 
> you should consider it more fully.  It's not a hack, and it doesn't 
> need to be complicated.

There is benefit to the current dumb implementation in that drivers
can use it without thinking too much, but yeah it could be that the
flushing range limit isn't too much of restriction on top.  I don't
know.  At this point, I'd prefer to remove request_module() from
elevator init path for the problem at hand.  If we need something more
involved, changing cookie usage rules definitely seems like an option.

Thanks.

-- 
tejun
--
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/