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

Date:	Thu, 21 Jun 2007 18:21:42 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	"Huang, Ying" <ying.huang@...el.com>
CC:	Greg K-H <greg@...ah.com>,
	Cornelia Huck <cornelia.huck@...ibm.com>,
	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 parallelism
 control

Huang, Ying wrote:
> I think the queue IDs of different subsystem need not to be exclusive.
> The subsystem can allocate queue IDs arbitrarily. If one queue ID is
> shared between several subsystems, corresponding probing will be
> serialized. This will slow down the probing unnecessarily, but there
> will be no race condition.

Parallelism between subsystems may be interesting during boot ==
"coldplug", /if/ the machine has time-consuming devices to probe on
/different/ types of buses.  Of course some machines do the really
time-consuming stuff on only one type of bus.  Granted, parallelism
betwen subsystems is not very interesting anymore later after boot ==
"hotplug".

[...]
> Whether is it possible that a new unit is inserted during probing
> kthread is running.

Nodes and units on nodes may came and go at arbitrary points in time,
and I'm sure similar things can be said about the majority of other bus
architectures or network architectures.  We take this into account.

(The old FireWire stack will re-enter the main loop of the bus scanning
thread sometime after a bus reset event signaled that nodes or units may
have appeared or disappeared.  The new FireWire stack will schedule
respective scanning workqueue jobs after such an event.)
-- 
Stefan Richter
-=====-=-=== -==- =-=-=
http://arcgraph.de/sr/
-
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/