Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752024AbdIJXn2 (ORCPT ); Sun, 10 Sep 2017 19:43:28 -0400 Received: from mail-io0-f172.google.com ([209.85.223.172]:35119 "EHLO mail-io0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751995AbdIJXn1 (ORCPT ); Sun, 10 Sep 2017 19:43:27 -0400 X-Google-Smtp-Source: AOwi7QCkomGSI69Z9a3NWKPhbg4kNDd0yQo7b6ogJA5IrwUTzb4QjijN7CiiPEhqhdKLUlWqwGhZDg== Subject: Re: Patch 0727d35de ("Make initramfs honor CONFIG_DEVTMPFS_MOUNT") breaks boot To: Michael Ellerman , Yury Norov Cc: Andrew Morton , "linux-kernel@vger.kernel.org" , Prarit Bhargava , Yang Shi , Rasmus Villemoes , Kees Cook , Emese Revfy , Petr Mladek , Fabian Frederick References: <20170522120550.ekrq6ipfmkdtlxjo@yury-N73SV> <7d91fb6b-9a21-ceb6-6c08-4bc14a15ada2@landley.net> <20170523080159.2yetdh4qqt2pmha6@yury-N73SV> <66dd96ec-b170-0bf6-7746-5466270b3e15@landley.net> <87fufta2gi.fsf@concordia.ellerman.id.au> From: Rob Landley Message-ID: <1fb53a8c-6c17-1de2-493c-0bff403c9ff9@landley.net> Date: Sun, 10 Sep 2017 18:43:24 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <87fufta2gi.fsf@concordia.ellerman.id.au> Content-Type: multipart/mixed; boundary="------------296A857C697EC73ADDA30F23" Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4510 Lines: 103 This is a multi-part message in MIME format. --------------296A857C697EC73ADDA30F23 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Taking another stab at this old issue from last merge window... > Rob Landley writes: >> On 05/23/2017 03:01 AM, Yury Norov wrote: >>> On Mon, May 22, 2017 at 09:07:54PM -0500, Rob Landley wrote: >>>> Your userspace mounted a tmpfs over /dev when it couldn't mount a second >>>> identical instance of devtmpfs over itself. If you had a static /dev in >>>> initramfs but didn't configure _in_ devtmpfs to your kernel, your broken >>>> error path would have taken that out too with a pointless tmpfs mount. >>> >>> CONFIG_DEVTMPFS_MOUNT is enabled on my machine, so I think your >>> suggestion is correct. But I didn't do that specifically - I run >>> almost default kernel based on Ubuntu 14.04 config and environment. >> >> I.E. ubuntu has a bug: they enabled CONFIG_DEVTMPFS_MOUNT and then >> launchd an initramfs instead (which didn't do the automount they >> requested so why request it), but if CONFIG_DEVTMPFS_MOUNT actually >> starts working in initramfs they have an insane error path that breaks >> the system, and does nothing _except_ break the system. ... On 05/25/2017 01:13 AM, Michael Ellerman wrote: > Hi Rob, > > This is breaking a bunch of my powerpc boxes, for the exact same > reason, they use a config that has DEVTMPFS_MOUNT=y and that trips > up the initramfs. I've continued to use this locally but should probably make another stab at submitting upstream. The obvious workaround until debian fixes its 100% obvious bug seems to be: diff --git a/fs/namespace.c b/fs/namespace.c index f8893dc..f57d5df 100644 --- a/fs/namespace.c +++ b/fs/namespace.c @@ -2417,7 +2417,17 @@ static int do_add_mount(struct mount *newmnt, struct path *path, int mnt_flags) err = -EBUSY; if (path->mnt->mnt_sb == newmnt->mnt.mnt_sb && path->mnt->mnt_root == path->dentry) + { + if (IS_ENABLED(CONFIG_DEVTMPFS_MOUNT) && + !strcmp(path->mnt->mnt_sb->s_type->name, "devtmpfs")) + { + printk(KERN_WARNING "Debian bug workaround for devtmpfs overmount."); + printk(KERN_WARNING "This line doesn't output for some reason."); + + err = 0; + } goto unlock; + } err = -EINVAL; if (d_is_symlink(newmnt->mnt.mnt_root)) Except for the second printk line: If you boot with rdinit=/bin/hush then the first time you mount -t devtmpfs /dev /dev after boot (with CONFIG_DEVTMPFS_MOUNT already having mounted it), you get the 0 return value but the last printk() doesn't output? The second and later times you repeat it, both printk() lines are output. What's up with printk? (I added the second printk because the _first_ one wasn't outputting that first time. Something is happening to flush the printk() queue instead of writing it out? Built for x86-64, miniconfig attached for reference. I tested commit 4dfc2788033d from yesterday.) Rob --------------296A857C697EC73ADDA30F23 Content-Type: text/plain; charset=UTF-8; name="x86_64.miniconf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="x86_64.miniconf" IyBtYWtlIEFSQ0g9eDg2IGFsbG5vY29uZmlnIEtDT05GSUdfQUxMQ09ORklHPXg4Nl82NC5t aW5pY29uZgojIG1ha2UgQVJDSD14ODYgLWogJChucHJvYykKIyBib290IGFyY2gveDg2L2Jv b3QvYnpJbWFnZQoKCkNPTkZJR182NEJJVD15CgpDT05GSUdfUENJPXkKQ09ORklHX0JMS19E RVZfU0Q9eQpDT05GSUdfQVRBPXkKQ09ORklHX0FUQV9TRkY9eQpDT05GSUdfQVRBX0JNRE1B PXkKQ09ORklHX0FUQV9QSUlYPXkKCkNPTkZJR19ORVRfVkVORE9SX0lOVEVMPXkKQ09ORklH X0UxMDAwPXkKQ09ORklHX1NFUklBTF84MjUwPXkKQ09ORklHX1NFUklBTF84MjUwX0NPTlNP TEU9eQpDT05GSUdfUlRDX0NMQVNTPXkKCgojIENPTkZJR19FTUJFRERFRCBpcyBub3Qgc2V0 CkNPTkZJR19FQVJMWV9QUklOVEs9eQpDT05GSUdfQklORk1UX0VMRj15CkNPTkZJR19CSU5G TVRfU0NSSVBUPXkKQ09ORklHX05PX0haPXkKQ09ORklHX0hJR0hfUkVTX1RJTUVSUz15CgpD T05GSUdfQkxLX0RFVj15CkNPTkZJR19CTEtfREVWX0lOSVRSRD15CkNPTkZJR19SRF9HWklQ PXkKCkNPTkZJR19CTEtfREVWX0xPT1A9eQpDT05GSUdfRVhUNF9GUz15CkNPTkZJR19FWFQ0 X1VTRV9GT1JfRVhUMj15CkNPTkZJR19WRkFUX0ZTPXkKQ09ORklHX0ZBVF9ERUZBVUxUX1VU Rjg9eQpDT05GSUdfTUlTQ19GSUxFU1lTVEVNUz15CkNPTkZJR19TUVVBU0hGUz15CkNPTkZJ R19TUVVBU0hGU19YQVRUUj15CkNPTkZJR19TUVVBU0hGU19aTElCPXkKQ09ORklHX0RFVlRN UEZTPXkKQ09ORklHX0RFVlRNUEZTX01PVU5UPXkKQ09ORklHX1RNUEZTPXkKQ09ORklHX1RN UEZTX1BPU0lYX0FDTD15CgpDT05GSUdfTkVUPXkKQ09ORklHX1BBQ0tFVD15CkNPTkZJR19V TklYPXkKQ09ORklHX0lORVQ9eQpDT05GSUdfSVBWNj15CkNPTkZJR19ORVRERVZJQ0VTPXkK I0NPTkZJR19ORVRfQ09SRT15CiNDT05GSUdfTkVUQ09OU09MRT15CkNPTkZJR19FVEhFUk5F VD15Cgo= --------------296A857C697EC73ADDA30F23--