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 From owner-freebsd-geom@freebsd.org Mon Nov 6 08:06:15 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 E2A4EE567B1 for ; Mon, 6 Nov 2017 08:06:14 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 96C1C64D60 for ; Mon, 6 Nov 2017 08:06:14 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id A28C8273C0; Mon, 6 Nov 2017 08:06:06 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id vA685oDO031858; Mon, 6 Nov 2017 08:05:50 GMT (envelope-from phk@phk.freebsd.dk) To: Colin Percival cc: freebsd-geom@freebsd.org Subject: Re: No automatic root mount holding for new geom providers? In-reply-to: <0100015f900017eb-91becde5-26c8-49f0-b593-751670ca42e0-000000@email.amazonses.com> From: "Poul-Henning Kamp" References: <0100015f900017eb-91becde5-26c8-49f0-b593-751670ca42e0-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31856.1509955550.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Mon, 06 Nov 2017 08:05:50 +0000 Message-ID: <31857.1509955550@critter.freebsd.dk> 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 08:06:15 -0000 -------- In message <0100015f900017eb-91becde5-26c8-49f0-b593-751670ca42e0-000000@e= mail. amazonses.com>, Colin Percival writes: >In practice, it seems that we avoid this by virtue of tasting new geoms b= eing >much faster than everything else the kernel does between when the disks a= re >attached and when vfs_mountroot runs, but I wouldn't want to rely on that= . > >Am I missing something? As I recall, the actual open will stall on the non-empty event-queue. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-geom@freebsd.org Mon Nov 6 08:58:33 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 73BF4E572EC for ; Mon, 6 Nov 2017 08:58:33 +0000 (UTC) (envelope-from 0100015f908d5f88-f54848aa-5a30-4571-865d-5f1e0c3dca32-000000@amazonses.com) Received: from a8-60.smtp-out.amazonses.com (a8-60.smtp-out.amazonses.com [54.240.8.60]) (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 3945765F31 for ; Mon, 6 Nov 2017 08:58:32 +0000 (UTC) (envelope-from 0100015f908d5f88-f54848aa-5a30-4571-865d-5f1e0c3dca32-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ae7m2yrxjw65l2cqdpjxuucyrvy564tn; d=tarsnap.com; t=1509958705; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=PkO7e8tXb088hUsKMOQZWqKO/EUG0gQ/kVGPPF9O4l4=; b=QWhvyPv9HW7j1Ewsxd9JxWN1Tge4qsIFh1lCsdt8qHdmMAV6ULEgswJioCaSaszO 4lTzMkIh8IuaKieuq2xgLhIgscjkjlowOBvuqH7iz3R4BE3u3Tt4ma8kowsiixEvhFF o+psp0svEv4snJcU3hnX84yRgHLUlvD0nLaF30kY= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1509958705; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=PkO7e8tXb088hUsKMOQZWqKO/EUG0gQ/kVGPPF9O4l4=; b=nuKoo2THCsfqa2StoeFGN7GctA12NVrBvMvCvo+D0MC2htuBZcYylMuPtefUYCAZ FWq0fFiyN7+csKW1/rBEPyzA1H5OQCiSSxnXu8MehkHJVQIrKXx89+bGjfKfzV+vVLq DPsEOyaSyiCX7k+cYbK3nq9jslW+D6PEnMfLj1yQ= Subject: Re: No automatic root mount holding for new geom providers? To: Poul-Henning Kamp References: <0100015f900017eb-91becde5-26c8-49f0-b593-751670ca42e0-000000@email.amazonses.com> <31857.1509955550@critter.freebsd.dk> Cc: freebsd-geom@freebsd.org From: Colin Percival Message-ID: <0100015f908d5f88-f54848aa-5a30-4571-865d-5f1e0c3dca32-000000@email.amazonses.com> Date: Mon, 6 Nov 2017 08:58:25 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <31857.1509955550@critter.freebsd.dk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SES-Outgoing: 2017.11.06-54.240.8.60 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 08:58:33 -0000 On 11/06/17 00:05, Poul-Henning Kamp wrote: > Colin Percival writes: >> 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? > > As I recall, the actual open will stall on the non-empty event-queue. Aha! I'm not sure about opens, but vfs_mountroot_wait calls g_waitidle, which waits until the event queue is empty. So any devices discovered before we hit vfs_mountroot will indeed have been fully digested before we try to mount the root filesystem. Thanks! -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid