linux-kernel - Re: Please revert 5adc55da4a7758021bcc374904b0f8b076508a11 (PCI_MULTITHREAD

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:	Tue, 8 May 2007 11:30:03 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Cornelia Huck <cornelia.huck@...ibm.com>
cc:	Adrian Bunk <bunk@...sta.de>, Greg K-H <greg@...ah.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Please revert 5adc55da4a7758021bcc374904b0f8b076508a11
 (PCI_MULTITHREAD_PROBE)

On Tue, 8 May 2007, Cornelia Huck wrote:
>
> > Threading at a driver level still does that (ie individual disks may be 
> > attached in some order that depends on how fast they are to respond), but 
> > in a much more controlled fashion, and only for drivers that explicitly 
> > say that they can do it.
> 
> How is that better? You still must rely on udev for persistent device
> names.

It's better because then the *driver* can decide whether it supports 
threaded probing or not.

The threaded PCI bus probing was totally and utterly broken exactly 
because many drivers were simply not willing or able to handle it.

Also, quite frankly, when this came up I already posted a much better 
approach for allowing arbitrary threading. It was ignored, but maybe you 
want to take a look.

See

	http://lkml.org/lkml/2006/10/27/185

for last time this came up. Any driver can decide to do

	execute_in_parallel(myprobe, myarguments);

and that really *simple* thing allows synchronization points 
("wait_for_parallel()") and arbitrary setting of the allowed parallelism.

I really think that is a *much* better approach. It allows, for example, 
the driver to do certain things (like name allocations and any 
particularly *fast* parts of probing) synchronously, and then do slow 
things (like spinning up disks and actually reading the partition tables) 
asynchronously.

Anyway, I will refuse to merge anything that does generic bus-level 
(unless the bus is something off-the-board like SCSI) parallelism, unless 
you can really show me how superior and stable it is. I seriously doubt 
you can. We tried it once, and it was a total disaster.

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