No automatic root mount holding for new geom providers?

[Colin Percival]

I've just been looking at the 'root mount hold' code (and users thereof)
and it seems to me that we may have a race condition which could result in
us attempting to mount root before the necessary geoms exist.

There are some places where we call root_mount_hold, but with a few
exceptions (usb, pccbb, storvsc, and zfs) they're all within individual
GEOM classes -- GPART and a variety of RAIDs.  In particular, there doesn't
seem to be any root mount holding when a disk first arrives.

I might be completely off here, since my understanding of the GEOM tasting
process (and how devices end up being GEOM disks at all) is very minimal, but
it seems that this could result in the following scenario:

<device probing> "Hey, there's a disk here, let's call it ada0"
<geom code> "Ok, posting a 'new provider' event to deal with this"
<vfs_mountroot> "Nobody has a root mount hold, let's mount root from ada0p2"
<vfs_mountroot> "Uh-oh, that geom doesn't exist."
*system stops booting*
<geom code> "Oh hey, there's this new provider I need to look at..."

In practice, it seems that we avoid this by virtue of tasting new geoms being
much faster than everything else the kernel does between when the disks are
attached and when vfs_mountroot runs, but I wouldn't want to rely on that.

Am I missing something?

-- 
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid