From owner-freebsd-geom@freebsd.org Mon Nov 6 06:24:13 2017 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80F31E52475 for ; Mon, 6 Nov 2017 06:24:13 +0000 (UTC) (envelope-from 0100015f900017eb-91becde5-26c8-49f0-b593-751670ca42e0-000000@amazonses.com) Received: from a8-237.smtp-out.amazonses.com (a8-237.smtp-out.amazonses.com [54.240.8.237]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4A47C276A for ; Mon, 6 Nov 2017 06:24:12 +0000 (UTC) (envelope-from 0100015f900017eb-91becde5-26c8-49f0-b593-751670ca42e0-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ae7m2yrxjw65l2cqdpjxuucyrvy564tn; d=tarsnap.com; t=1509949446; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type:Content-Transfer-Encoding; bh=WiqM+gqDNMLI61pg+7SSZCUANcyrFxk1lgjn2C0k/Zk=; b=I0T+gCbejVfKqeHQrymQrKliayFMt6GkV2s7zIKiXWjVFB+tBG09mqdjdiBV+zvK vIZM7ylx5ebeKquNNjAatabrCe91UbK8RoQygLXEDB1PcOP4OCbhMWdvxMae20HZUye eIFxi6bm9Wa3/CVemkj81/9H5GKBiTjsOdJ45/BE= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1509949446; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=WiqM+gqDNMLI61pg+7SSZCUANcyrFxk1lgjn2C0k/Zk=; b=g38rzzJCdKzNaG2RzXujUhAoMgVHlFmd9LAhP4D4skdRORR1+Dq9KYJrdW45BtFD nXhi1IlHBnoLn2UDjdgNQGnRSDK67yPO7vPlZh1M3OxktgZEEclU72FWkar3BMdrdu7 lMeDYrTSi55f60Fe715MK4ppV8auP6m0opUYNygA= To: freebsd-geom@freebsd.org From: Colin Percival Subject: No automatic root mount holding for new geom providers? Message-ID: <0100015f900017eb-91becde5-26c8-49f0-b593-751670ca42e0-000000@email.amazonses.com> Date: Mon, 6 Nov 2017 06:24:06 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SES-Outgoing: 2017.11.06-54.240.8.237 Feedback-ID: 1.us-east-1.Lv9FVjaNvvR5llaqfLoOVbo2VxOELl7cjN0AOyXnPlk=:AmazonSES X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 06:24:13 -0000 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: "Hey, there's a disk here, let's call it ada0" "Ok, posting a 'new provider' event to deal with this" "Nobody has a root mount hold, let's mount root from ada0p2" "Uh-oh, that geom doesn't exist." *system stops booting* "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