Date: Mon, 6 Nov 2017 06:24:06 +0000 From: Colin Percival <cperciva@tarsnap.com> To: freebsd-geom@freebsd.org Subject: No automatic root mount holding for new geom providers? Message-ID: <0100015f900017eb-91becde5-26c8-49f0-b593-751670ca42e0-000000@email.amazonses.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0100015f900017eb-91becde5-26c8-49f0-b593-751670ca42e0-000000>