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:	Wed, 9 May 2007 09:58:12 +0200
From:	Cornelia Huck <cornelia.huck@...ibm.com>
To:	david@...g.hm
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	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 13:26:00 -0700 (PDT),
david@...g.hm wrote:

> is it really enough to do the sync followed by the async piece?
> 
> it seems to me that there may be a need for three steps
> 
> 1. prep (sync, what we do today)
> which will all complete before
> 2. parallel (async)
> which will all complete before
> 3. cleanup (sync)
> 
> for some busses you can do the device enumeration in the prep phase, but I 
> would expect that for others you can't enumerate the devices until you 
> actually go looking for them. so by allowing the cleanup phase you have a 
> spot that can order everything as if the second phase was sequential.
> 
> I would expect that almost no drivers would use all three, but I could see 
> some useing #1 and #2 while others use #2 and #3

Hm, how about:
1. ->probe() called (wait until it is finished)
2. ->probe_async() called (only kick off, don't wait, go to next device)
3. bus waits until all async probes have returned

This would imply a wait mechanism on the bus, like upping a counter for
each successfully called ->probe_async(), the driver downing the
counter when all actions triggered by ->probe_async() have finshed, and
the bus waiting until the counter has reached 0.

(Individual drivers can have 1., 2., or 1. & 2. A bus may support 1.
(like now), 2. & 3. or 1., 2. and 3.)

> in any case there needs to be a way to wait until the async portion 
> finishes before going on to next steps (you don't want to try to probe 
> drives for md partitions until the drives have finished spinning up for 
> example)

Agreed. Would it be enough if we only have one bus in flight
simuntaneously?
-
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/