linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Rob Landley <rob@landley.net>, Yury Norov <ynorov@caviumnetworks.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Prarit Bhargava <prarit@redhat.com>,
	Yang Shi <yang.shi@linaro.org>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Kees Cook <keescook@chromium.org>,
	Emese Revfy <re.emese@gmail.com>, Petr Mladek <pmladek@suse.com>,
	Fabian Frederick <fabf@skynet.be>
Subject: Re: Patch 0727d35de ("Make initramfs honor CONFIG_DEVTMPFS_MOUNT") breaks boot
Date: Thu, 25 May 2017 16:13:33 +1000	[thread overview]
Message-ID: <87fufta2gi.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <66dd96ec-b170-0bf6-7746-5466270b3e15@landley.net>

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.

Rob Landley <rob@landley.net> 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.

Sure. But prior to your patch the only reason mounting devtmpfs could
fail was because of something being broken, it was never automatically
mounted. So we've changed the set of possibilities out from under the
initramfs scripts.

I agree it's not the greatest error handling ever, but it's pretty rude
to break booting on existing working setups. If nothing else it makes
bisection a nightmare.

>> So the proper way is to remove broken
>> config option and introduce new one. BTW, I see it is used once in
>> drivers/base/devtmpfs.c.
>
> How does removing the broken config option (or renaming it to
> CONFIG_DEFTMPFS_UBUNTU_IS_BROKEN) _not_ impact systems that were
> previously happily using it in the contexts where it already worked?

I don't think that's what Yury's suggesting, and indeed it wouldn't work.

What would work, is to add a new config option, perhaps
CONFIG_DEVTMPFS_MOUNT_INITRAMFS, which is 'default n'. Then existing
setups continue to work, and people who want it mounted in the initramfs
can enable the new option.

cheers

  parent reply	other threads:[~2017-05-25  6:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-22 12:05 Patch 0727d35de ("Make initramfs honor CONFIG_DEVTMPFS_MOUNT") breaks boot Yury Norov
2017-05-23  2:07 ` Rob Landley
2017-05-23  8:01   ` Yury Norov
2017-05-23 17:40     ` Rob Landley
2017-05-23 21:32       ` Yury Norov
2017-05-23 23:08         ` Yury Norov
2017-05-25  5:55           ` Rob Landley
2017-05-25  6:13       ` Michael Ellerman [this message]
2017-09-10 23:43         ` Rob Landley
2017-09-11 11:45           ` Petr Mladek
2017-09-12  0:42             ` Sergey Senozhatsky
2017-09-13  2:45             ` Rob Landley
     [not found] ` <CAP2kuOwkM7hr5nOtrRSRdXcPi2y3KHVf4yFdDN1JW1o_mWo0yw@mail.gmail.com>
2017-05-25 13:44   ` Leo Yan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fufta2gi.fsf@concordia.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=akpm@linux-foundation.org \
    --cc=fabf@skynet.be \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=pmladek@suse.com \
    --cc=prarit@redhat.com \
    --cc=re.emese@gmail.com \
    --cc=rob@landley.net \
    --cc=yang.shi@linaro.org \
    --cc=ynorov@caviumnetworks.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).