Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp5796254ybi; Tue, 4 Jun 2019 12:23:42 -0700 (PDT) X-Google-Smtp-Source: APXvYqyYVaFJ45BJ0nzG2SDRjTfQRmVFi4BbB+DjFNGOwxB9UpIjxXQGMGwdsTzioufzn7OTtSba X-Received: by 2002:a62:e801:: with SMTP id c1mr16940891pfi.41.1559676222437; Tue, 04 Jun 2019 12:23:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559676222; cv=none; d=google.com; s=arc-20160816; b=mJ2GLt1uRBeK4q14roPRTdF7KoKiswfM3xRKoNbkOxAU07jvwfNmMFTVb5Ql5/rSPa UN9ZLV8ZbY/wGlLSyZCEVfE/jTSxZcvg5r1hTMarYspxjnNb8NVrN6ksrIsBlv4JtCh9 X/L08lFvq2WRmz2VZ2yhYNwRrKRMTqavLVFasI+34cfoJal6xVFxpFUPqkMusl4hWd7K cPtJzj5RPCm8vE0oOVWU6gbgoamLW/yVw+mB0yZhOe/+EFJ714Gmpw53o2jwV3HepMbM yrYydZjjbwF9nDjMOM6gRtKUZumlih+ihhMTqWZlKN86B8FlSpMcfZoUvAvnztalAmlj 3rOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:organization:references:in-reply-to:date:cc:to:from :subject:message-id; bh=sKzgJ+Ckecdidw8wxZeXCYoS8+vaQ3FS3YGh5+HSRRw=; b=YeVA00gAwghQ/dAUm4wmn0W3TRbG3ZRJgqiQ70LaMvYGmt/qfogvJy/tplSbFxBNM7 m8nei1fjNRb7+jEs0udlL0vcNk6AD4uiXf1MGtACPPBKuqGnQJ9HjMhWiCIRRiP/89Lh cQlyJbEKdMGmuoHWhoaDlDTHK5aaF7w2Cj8q2Ou4FyrH3CQkCSkF6j1AqbxDsPxbzyWQ CZeegDEaAVjck1yb248j02vad1Rb5FtQkgZzYeycB8Zm39HRXY6gplVUo4t5isxPGACX qyGZcBjPMDW4cASVNeB7Ya/9+0PgRNYrtm5loSpbJ+ltQtiqRd1b0+JjJ2hVaQWBQvMH IMDw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 9si23112970pgu.189.2019.06.04.12.23.10; Tue, 04 Jun 2019 12:23:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726373AbfFDTVX (ORCPT + 99 others); Tue, 4 Jun 2019 15:21:23 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:44130 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726179AbfFDTVX (ORCPT ); Tue, 4 Jun 2019 15:21:23 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: ezequiel) with ESMTPSA id 7052C281D9F Message-ID: <9460817290d5846a34b81470b15ac36d88a08aad.camel@collabora.com> Subject: Re: [PATCH v12] dm: add support to directly boot to a mapped device From: Ezequiel Garcia To: Helen Koike , Stephen Boyd , dm-devel@redhat.com Cc: wad@chromium.org, keescook@chromium.org, snitzer@redhat.com, linux-doc@vger.kernel.org, richard.weinberger@gmail.com, linux-kernel@vger.kernel.org, linux-lvm@redhat.com, enric.balletbo@collabora.com, kernel@collabora.com, agk@redhat.com Date: Tue, 04 Jun 2019 16:21:10 -0300 In-Reply-To: References: <20190221203334.24504-1-helen.koike@collabora.com> <5cf5a724.1c69fb81.1e8f0.08fb@mx.google.com> Organization: Collabora Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Stephen, On Tue, 2019-06-04 at 14:38 -0300, Helen Koike wrote: > Hi Stephen, > > On 6/3/19 8:02 PM, Stephen Boyd wrote: > > Quoting Helen Koike (2019-02-21 12:33:34) > > > Add a "create" module parameter, which allows device-mapper targets to be > > > configured at boot time. This enables early use of dm targets in the boot > > > process (as the root device or otherwise) without the need of an initramfs. > > > > > > The syntax used in the boot param is based on the concise format from the > > > dmsetup tool to follow the rule of least surprise: > > > > > > sudo dmsetup table --concise /dev/mapper/lroot > > > > > > Which is: > > > dm-mod.create=,,,,[,
+][;,,,,
[,
+]+] > > > > > > Where, > > > ::= The device name. > > > ::= xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | "" > > > ::= The device minor number | "" > > > ::= "ro" | "rw" > > >
::= > > > ::= "verity" | "linear" | ... > > > > > > For example, the following could be added in the boot parameters: > > > dm-mod.create="lroot,,,rw, 0 4096 linear 98:16 0, 4096 4096 linear 98:32 0" root=/dev/dm-0 > > > > > > Only the targets that were tested are allowed and the ones that doesn't > > > change any block device when the dm is create as read-only. For example, > > > mirror and cache targets are not allowed. The rationale behind this is > > > that if the user makes a mistake, choosing the wrong device to be the > > > mirror or the cache can corrupt data. > > > > > > The only targets allowed are: > > > * crypt > > > * delay > > > * linear > > > * snapshot-origin > > > * striped > > > * verity > > > > > > Co-developed-by: Will Drewry > > > Co-developed-by: Kees Cook > > > Co-developed-by: Enric Balletbo i Serra > > > Signed-off-by: Helen Koike > > > > > > --- > > > > > > > I'm trying to boot a mainline linux kernel on a chromeos device with dm > > verity and a USB stick but it's not working for me even with this patch. > > I've had to hack around two problems: > > > > 1) rootwait isn't considered > > > > 2) verity doesn't seem to accept UUID for or > > > > For the first problem, it happens every boot for me because I'm trying > > to boot off of a USB stick and it's behind a hub that takes a few > > seconds to enumerate. If I hack up the code to call dm_init_init() after > > the 'rootdelay' cmdline parameter is used then I can make this work. It > > would be much nicer if the whole mechanism didn't use a late initcall > > though. If it used a hook from prepare_namespace() and then looped > > waiting for devices to create when rootwait was specified it would work. > > The patch was implemented with late initcall partially to be contained > in drivers/md/*, but to support rootwait, adding a hook from > prepare_namespace seems the way to go indeed. > Thanks for bringing this up. Helen and I have been looking at this code, and we think it's possible to move things around and add some helpers, so we can implement rootwait behavior, without actually cluttering init/do_mounts.c. And along the way, we might get the chance to clean-up this code even further. Regards, Eze