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 19:07:36 +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>,
	Duncan Sands <duncan.sands@...h.u-psud.fr>
Subject: Re: Please revert 5adc55da4a7758021bcc374904b0f8b076508a11
 (PCI_MULTITHREAD_PROBE)

On Wed, 9 May 2007 09:18:10 -0700 (PDT),
david@...g.hm wrote:

> I'm not worried about notification to userspace, I'm worried about devices 
> getting registered during the async stage appearing in different orders on 
> different boots due to different timeings.

Ah, now I think I understand what you mean. You're talking about stuff
like block devices or net devices, right?

> 
> if you can identify the device well enough to register it quickly then the 
> approach that Linus proposed works well, which is
> 
> sync probe, identify devices, register devices
> async initialize devices
> wait for all async to complete
> 
> however I'm talking about cases where you can't fully identify the devices 
> (at least not well enough to register them with the kernel) and am saying 
> that doing
> 
> sync probe
> async initialize device, register device
> wait for all async to complete
> 
> results in unpredictable device ordering, but if instead you did
> 
> sync probe
> async initialize device
> sync wait for all async to complete, register device
> 
> you can get back to predictable ordering

Hm, so that sound like a case for a distinct setup() routine:

1. bus calls ->probe(), which return synchronously
2. bus calls ->probe_async() for all devices (optional)
3. bus waits for all probes to finish
4. bus calls ->setup() for all devices (which does the registering)

(->setup() can but need not be sync, although it should be for your
case)

Note that ordering is not guaranteed on hotpluggable busses anyway, and
if you use ->setup() as a function that may or may not be called later
on, there's no ordering guarantee either. (Unless the bus/device driver
implements something to that effect, or you have udev rules in place.)
-
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/