linux-kernel - Re: [PATCH] driver core: multithreaded probing

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] [day] [month] [year] [list]

Date:	Tue, 3 Jul 2007 11:33:52 +0200
From:	Cornelia Huck <cornelia.huck@...ibm.com>
To:	Greg KH <greg@...ah.com>
Cc:	"Huang, Ying" <ying.huang@...el.com>,
	Stefan Richter <stefanr@...6.in-berlin.de>,
	Adrian Bunk <bunk@...sta.de>, david@...g.hm,
	David Miller <davem@...emloft.net>,
	Duncan Sands <duncan.sands@...h.u-psud.fr>,
	Phillip Susi <psusi@....rr.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] driver core: multithreaded probing - more
 parallelismcontrol

On Mon, 25 Jun 2007 01:16:24 -0700,
Greg KH <greg@...ah.com> wrote:

[I'm a bit late to the party, but...]

> On Sun, Jun 24, 2007 at 11:04:13PM +0800, Huang, Ying wrote:

> > There does exist multithreaded device probing in current driver core
> > implementation, supposing two devices are hot-plugged at the same time.
> 
> No, that is a bus-specific thing, and no bus that I know of supports
> that at this time.

The s390 channel subsystem busses should be fine with any parallelism,
especially as the css bus kicks off tons of probes (device recognition)
at the same time. Any ccw driver must be able to be handle to be called
for many devices in parallel as well (like, when someone attaches their
shiny new storage subsystem to the LPAR and some thousands of dasds
become available).

> 
> > But, many device drivers are written without this taken into account.
> 
> That's why no bus does this :)

It is possible for busses for a small set of device drivers (like the
s390 busses; maybe there are others). It looks like a bad idea to try
this for PCI :)

> 
> > I think it may be better to make default device probing process more
> > single-threaded in the driver core. The single-thread workqueue or some
> > customized version of workqueue like that implemented by my patch can be
> > used for this. The parallel control mechanism can be used to implement
> > multithreaded device probing in needed subsystems too.
> 
> But remember, the individual busses already do this all in a single
> thread anyway, nothing is needed in the driver core to do this.

I think I could make good use of some more parallelism control (for
throttling or so). Not sure if it should really sit at the driver
core level, but that would avoid reinventing the wheel.

[Goes reading the original patch]

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