linux-kernel - Re: 3.0-rc6: USB khubd deadlock when hub is powered down

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.1107081005080.2208-100000@iolanthe.rowland.org>
Date:	Fri, 8 Jul 2011 10:12:06 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
cc:	Sarah Sharp <sarah.a.sharp@...ux.intel.com>,
	Greg KH <greg@...ah.com>, <linux-usb@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: 3.0-rc6: USB khubd deadlock when hub is powered down

On Thu, 7 Jul 2011, Stefan Richter wrote:

> > > On a general level, the last few kernel.org releases have all been rather
> > > weak.  Dissatisfied,
> > 
> > For USB regressions or the kernel overall?
> 
> Kernel overall.  USB unplug issues have been there before, but not as
> reproducible as this one now.  (Which is apparently fixed for me now.)
> 
> I felt compelled to comment on Alan's sentence though because this does
> not sound like the 2.6 development approach at all.  (Some other
> subsystem projects, outside USB, ignore that approach anyway and work 2.5
> style.)

In general, adding support for USB-3.0 has been a tremendous job (of 
which Sarah has done the lion's share of the work), involving not just 
adding a new driver but also making significant changes to the 
subsystem core.  Those changes have been sufficiently complicated that 
things haven't settled down yet.

Particularly since it has now become clear that a key implementation
decision (to allocate periodic bandwidth dynamically, as it is used,
rather than statically) needs to be reversed.  The fan-out effects from
this will require changes to several other drivers as well, and this is 
all still in the design stage.  Thus, we are forced to limp along with 
a hacky, not-entirely-correct implementation until everything can be 
put right.  I don't expect this to happen quickly.

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/