Race between mtdconcat and rootfs detection?

[Catalin Patulea]

Hi,

I've got a rootfs on an mtdconcat device and I think I'm seeing a race
between the mtdconcat device coming up and prepare_namespace looking
for the rootfs. Under some circumstances, I get "VFS: Unable to mount
root fs on unknown-block(0,0)" partway into partition detection.

Adding rootwait=5 fixes it, but I would rather not use that in the
long term. I'm trying to find a way to block prepare_namespace from
doing rootfs detection until the mtdconcat comes up (possibly hooks:
device probing, async_synchronize_full). I can provide boot logs if
anyone wishes to double-check the diagnosis.

The mtdconcat is created from an mtd notifier on the contituent mtds.
I can see a few different ways of going from there:

1) Call mtd_device_register synchronously. This causes deadlock
because notifiers run under mtd_table_mutex [1] and
mtd_device_register tries to acquire it a second time.

2) schedule_work(&call_mtd_device_register): this causes the race I
described earlier where device probing "completes", prepare_namespace
looks for the rootfs and panics before mtdconcat comes up.

3) async_schedule(&call_mtd_device_register): This is a potential fix
because prepare_namespace does async_synchronize_full [1]. But
mtd_device_register -> parse_mtd_partitions -> request_module, which
is disallowed in async.

4) Create a driver/device pair. prepare_namespace ->
wait_for_device_probe, which waits for active probes to come down to 0
[3]. But this adds some boilerplate so I would rather leave it as a
last resort.

Any other options I haven't considered? I'm pretty new at kernel
development and not sure what standard practice is for this sort of
thing.

Catalin

[1] http://lxr.linux.no/linux+v3.10.9/drivers/mtd/mtdcore.c#L403
[2] http://lxr.linux.no/linux+v3.10.9/init/do_mounts.c#L551,
http://lxr.linux.no/linux+v3.10.9/drivers/base/dd.c#L356
[3] http://lxr.linux.no/linux+v3.10.9/drivers/base/dd.c#L355