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

[Tejun Heo <tj@kernel.org>]

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