Re: Please revert 5adc55da4a7758021bcc374904b0f8b076508a11(PCI_MULTITHREAD_PROBE)

From: david
Date: Wed May 09 2007 - 13:12:31 EST


On Wed, 9 May 2007, Cornelia Huck wrote:

On Wed, 9 May 2007 09:18:10 -0700 (PDT),
david@xxxxxxx 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?

they will work as examples, but I am not sure that that is the limit of this sort of problem


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)

this is exactly what I've been trying to describe.

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

if it's not sync then you have race conditions again

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.)

correct.

David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/