| Message ID | 4aa9cb26-f868-0720-e5c8-3c4e08afad20@landley.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Le 14/09/2017 à 01:51, Rob Landley a écrit : > From: Rob Landley <rob@landley.net> > > Make initramfs honor CONFIG_DEVTMPFS_MOUNT, and move > /dev/console open after devtmpfs mount. > > Add workaround for Debian bug that was copied by Ubuntu. Is that a bug only for Debian ? Why ? Why should a Debian bug be fixed by a workaround in the mainline kernel ? > > Signed-off-by: Rob Landley <rob@landley.net> > --- > > v2 discussion: http://lkml.iu.edu/hypermail/linux/kernel/1705.2/05611.html > > drivers/base/Kconfig | 14 ++++---------- > fs/namespace.c | 14 ++++++++++++++ > init/main.c | 15 +++++++++------ > 3 files changed, 27 insertions(+), 16 deletions(-) > > diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig > index f046d21..97352d4 100644 > --- a/drivers/base/Kconfig > +++ b/drivers/base/Kconfig > @@ -48,16 +48,10 @@ config DEVTMPFS_MOUNT > bool "Automount devtmpfs at /dev, after the kernel mounted the rootfs" > depends on DEVTMPFS > help > - This will instruct the kernel to automatically mount the > - devtmpfs filesystem at /dev, directly after the kernel has > - mounted the root filesystem. The behavior can be overridden > - with the commandline parameter: devtmpfs.mount=0|1. > - This option does not affect initramfs based booting, here > - the devtmpfs filesystem always needs to be mounted manually > - after the rootfs is mounted. > - With this option enabled, it allows to bring up a system in > - rescue mode with init=/bin/sh, even when the /dev directory > - on the rootfs is completely empty. > + Automatically mount devtmpfs at /dev on the root filesystem, which > + lets the system to come up in rescue mode with [rd]init=/bin/sh. > + Override with devtmpfs.mount=0 on the commandline. Initramfs can > + create a /dev dir as needed, other rootfs needs the mount point. Why modifying the initial text ? Why talking about rescue mode only, whereas this feature mainly concerns the standard mode. > > config STANDALONE > bool "Select only drivers that don't need compile-time external firmware" > diff --git a/fs/namespace.c b/fs/namespace.c > index f8893dc..06057d7 100644 > --- a/fs/namespace.c > +++ b/fs/namespace.c > @@ -2417,7 +2417,21 @@ 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")) > + { > + /* Debian's kernel config enables DEVTMPFS_MOUNT, then > + its initramfs setup script tries to mount devtmpfs > + again, and if the second mount-over-itself fails > + the script overmounts a tmpfs on /dev to hide the > + existing contents, then boot fails with empty /dev. */ Does it matter for the kernel code what Debian's kernel config does ? > + printk(KERN_WARNING "Debian bug workaround for devtmpfs overmount."); Is this log message worth it when this modification goes in mainline kernel ? If so, pr_err() should be used instead. > + > + err = 0; > + } > goto unlock; > + } > > err = -EINVAL; > if (d_is_symlink(newmnt->mnt.mnt_root)) > diff --git a/init/main.c b/init/main.c > index 0ee9c686..0d8e5ec 100644 > --- a/init/main.c > +++ b/init/main.c > @@ -1065,12 +1065,6 @@ static noinline void __init kernel_init_freeable(void) > > do_basic_setup(); > > - /* Open the /dev/console on the rootfs, this should never fail */ > - if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0) > - pr_err("Warning: unable to open an initial console.\n"); > - > - (void) sys_dup(0); > - (void) sys_dup(0); > /* > * check if there is an early userspace init. If yes, let it do all > * the work > @@ -1082,8 +1076,17 @@ static noinline void __init kernel_init_freeable(void) > if (sys_access((const char __user *) ramdisk_execute_command, 0) != 0) { > ramdisk_execute_command = NULL; > prepare_namespace(); > + } else if (IS_ENABLED(CONFIG_DEVTMPFS_MOUNT)) { > + sys_mkdir("/dev", 0755); Why not, but couldn't we also expect the initramfs to already contains that mountpoint ? > + devtmpfs_mount("/dev"); > } > > + /* Open the /dev/console on the rootfs, this should never fail */ > + if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0) > + pr_err("Warning: unable to open an initial console.\n"); > + (void) sys_dup(0); > + (void) sys_dup(0); > + > /* > * Ok, we have completed the initial bootup, and > * we're essentially up and running. Get rid of the > Christophe -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Sep 13, 2017 at 06:51:25PM -0500, Rob Landley wrote: > From: Rob Landley <rob@landley.net> > > Make initramfs honor CONFIG_DEVTMPFS_MOUNT, and move > /dev/console open after devtmpfs mount. > > Add workaround for Debian bug that was copied by Ubuntu. > > Signed-off-by: Rob Landley <rob@landley.net> > --- > > v2 discussion: http://lkml.iu.edu/hypermail/linux/kernel/1705.2/05611.html > > drivers/base/Kconfig | 14 ++++---------- > fs/namespace.c | 14 ++++++++++++++ > init/main.c | 15 +++++++++------ > 3 files changed, 27 insertions(+), 16 deletions(-) Always run scripts/checkpatch.pl so you don't get grumpy emails from reviewers telling you to run scripts/checkpatch.pl... telling you to run scripts/checkpatch.pl... telling you to run scripts/checkpatch.pl... telling you to run scripts/checkpatch.pl... -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/14/2017 04:17 AM, Christophe LEROY wrote: > Le 14/09/2017 à 01:51, Rob Landley a écrit : >> From: Rob Landley <rob@landley.net> >> >> Make initramfs honor CONFIG_DEVTMPFS_MOUNT, and move >> /dev/console open after devtmpfs mount. >> >> Add workaround for Debian bug that was copied by Ubuntu. > > Is that a bug only for Debian ? Why ? Look down, specifically this bit: >> v2 discussion: >> http://lkml.iu.edu/hypermail/linux/kernel/1705.2/05611.html That's some discussion of version 2 of this patch, which was merged for a while last dev cycle, then backed out again because it triggered the same bug in a number of system init scripts: http://lkml.iu.edu/hypermail/linux/kernel/1705.2/07072.html http://lkml.iu.edu/hypermail/linux/kernel/1705.3/01182.html http://lkml.iu.edu/hypermail/linux/kernel/1705.3/01505.html http://lkml.iu.edu/hypermail/linux/kernel/1705.3/01320.html All of whom copied the broken error "recovery" path from debian. If they checked whether it was already mounted, or didn't _blank_ the /dev directory in response to mounting the exact same filesystem over itself giving -EBUSY, the system would work fine. Heck, if you built a kernel with a static /dev in initramfs and no devtmpfs configured in, the script would break things exactly the same way. The breakage is that script takes a hammer to a perfectly functional /dev directory and then continues the boot with an empty /dev. That's bonkers. > Why should a Debian bug be fixed by a workaround in the mainline kernel ? That was my argument last time, and the answer was "Breaking userspace is bad, mmmkay." Even when userspace is doing something REALLY OBVIOUSLY STUPID and it is _clearly_ their fault, as long as they got there first they've established the status quo and it doesn't matter how silly it is. This was explicitly stated to me here: http://lkml.iu.edu/hypermail/linux/kernel/1705.3/03292.html I.E. don't argue with me, argue with him. :) So, I added a workaround with a printk in hopes of embarassing them into someday fixing it. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, 16 Sep 2017, Rob Landley wrote: > So, I added a workaround with a printk in hopes of embarassing them into > someday fixing it. Oh, it will be fixed in Debian alright. I am just waiting the issue to settle a bit to file the bug reports, or maybe even send in the Debian patches myself (note that I am not responsible for the code in question, so I am not wearing a brown paperbag at this time). Even if I didn't do it, there are several other Debian Developers reading LKML that could do it (provided they noticed this specific thread and are aware of the situation) :p I can even push for the fixes to be accepted into the stable and oldstable branches of Debian, but that can take anything from a few weeks to several months, due to the way our stable releases work. But it would eventually happen. Whether such fixes will ever make it to LTS branches, especially Ubuntu's, *that* I don't know.
On 09/17/2017 08:51 AM, Henrique de Moraes Holschuh wrote: > On Sat, 16 Sep 2017, Rob Landley wrote: >> So, I added a workaround with a printk in hopes of embarassing them into >> someday fixing it. > > Oh, it will be fixed in Debian alright. Cool! But part of the problem is people upgrade the kernel on existing deployed root filesystems, some of which are a fork off of a fork off of debian, so we won't exhaust the broken userspace for probably a couple years. I'd put it in feature-removal-schedule.txt but Linus zapped that, so... > I am just waiting the issue to > settle a bit to file the bug reports, or maybe even send in the Debian > patches myself (note that I am not responsible for the code in question, > so I am not wearing a brown paperbag at this time). Even if I didn't do > it, there are several other Debian Developers reading LKML that could do > it (provided they noticed this specific thread and are aware of the > situation) :p There was a previous thread last merge window they didn't notice. I was hoping the warning would be obvious enough. :) > I can even push for the fixes to be accepted into the stable and > oldstable branches of Debian, but that can take anything from a few > weeks to several months, due to the way our stable releases work. But > it would eventually happen. > > Whether such fixes will ever make it to LTS branches, especially > Ubuntu's, *that* I don't know. I have no idea what that powerpc system was, the guy didn't say... Rob -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Rob Landley <rob@landley.net> writes: > On 09/14/2017 04:17 AM, Christophe LEROY wrote: >> Le 14/09/2017 à 01:51, Rob Landley a écrit : >>> From: Rob Landley <rob@landley.net> >>> >>> Make initramfs honor CONFIG_DEVTMPFS_MOUNT, and move >>> /dev/console open after devtmpfs mount. >>> >>> Add workaround for Debian bug that was copied by Ubuntu. >> >> Is that a bug only for Debian ? Why ? > > Look down, specifically this bit: > >>> v2 discussion: >>> http://lkml.iu.edu/hypermail/linux/kernel/1705.2/05611.html > > That's some discussion of version 2 of this patch, which was merged for > a while last dev cycle, then backed out again because it triggered the > same bug in a number of system init scripts: > > http://lkml.iu.edu/hypermail/linux/kernel/1705.2/07072.html > http://lkml.iu.edu/hypermail/linux/kernel/1705.3/01182.html > http://lkml.iu.edu/hypermail/linux/kernel/1705.3/01505.html > http://lkml.iu.edu/hypermail/linux/kernel/1705.3/01320.html > > All of whom copied the broken error "recovery" path from debian. If they > checked whether it was already mounted, or didn't _blank_ the /dev > directory in response to mounting the exact same filesystem over itself > giving -EBUSY, the system would work fine. Heck, if you built a kernel > with a static /dev in initramfs and no devtmpfs configured in, the > script would break things exactly the same way. The breakage is that > script takes a hammer to a perfectly functional /dev directory and then > continues the boot with an empty /dev. That's bonkers. > >> Why should a Debian bug be fixed by a workaround in the mainline kernel ? > > That was my argument last time, and the answer was "Breaking userspace > is bad, mmmkay." Even when userspace is doing something REALLY OBVIOUSLY > STUPID and it is _clearly_ their fault, as long as they got there first > they've established the status quo and it doesn't matter how silly it is. > > This was explicitly stated to me here: > > http://lkml.iu.edu/hypermail/linux/kernel/1705.3/03292.html > > I.E. don't argue with me, argue with him. :) I'm still here. And I'm still right :) No one wants their system to stop booting because of this obscure functionality. Just put it behind a new config option which defaults off. No workarounds required, no broken systems, no long email threads required. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig index f046d21..97352d4 100644 --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -48,16 +48,10 @@ config DEVTMPFS_MOUNT bool "Automount devtmpfs at /dev, after the kernel mounted the rootfs" depends on DEVTMPFS help - This will instruct the kernel to automatically mount the - devtmpfs filesystem at /dev, directly after the kernel has - mounted the root filesystem. The behavior can be overridden - with the commandline parameter: devtmpfs.mount=0|1. - This option does not affect initramfs based booting, here - the devtmpfs filesystem always needs to be mounted manually - after the rootfs is mounted. - With this option enabled, it allows to bring up a system in - rescue mode with init=/bin/sh, even when the /dev directory - on the rootfs is completely empty. + Automatically mount devtmpfs at /dev on the root filesystem, which + lets the system to come up in rescue mode with [rd]init=/bin/sh. + Override with devtmpfs.mount=0 on the commandline. Initramfs can + create a /dev dir as needed, other rootfs needs the mount point. config STANDALONE bool "Select only drivers that don't need compile-time external firmware" diff --git a/fs/namespace.c b/fs/namespace.c index f8893dc..06057d7 100644 --- a/fs/namespace.c +++ b/fs/namespace.c @@ -2417,7 +2417,21 @@ 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")) + { + /* Debian's kernel config enables DEVTMPFS_MOUNT, then + its initramfs setup script tries to mount devtmpfs + again, and if the second mount-over-itself fails + the script overmounts a tmpfs on /dev to hide the + existing contents, then boot fails with empty /dev. */ + printk(KERN_WARNING "Debian bug workaround for devtmpfs overmount."); + + err = 0; + } goto unlock; + } err = -EINVAL; if (d_is_symlink(newmnt->mnt.mnt_root)) diff --git a/init/main.c b/init/main.c index 0ee9c686..0d8e5ec 100644 --- a/init/main.c +++ b/init/main.c @@ -1065,12 +1065,6 @@ static noinline void __init kernel_init_freeable(void) do_basic_setup(); - /* Open the /dev/console on the rootfs, this should never fail */ - if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0) - pr_err("Warning: unable to open an initial console.\n"); - - (void) sys_dup(0); - (void) sys_dup(0); /* * check if there is an early userspace init. If yes, let it do all * the work @@ -1082,8 +1076,17 @@ static noinline void __init kernel_init_freeable(void) if (sys_access((const char __user *) ramdisk_execute_command, 0) != 0) { ramdisk_execute_command = NULL; prepare_namespace(); + } else if (IS_ENABLED(CONFIG_DEVTMPFS_MOUNT)) { + sys_mkdir("/dev", 0755); + devtmpfs_mount("/dev"); } + /* Open the /dev/console on the rootfs, this should never fail */ + if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0) + pr_err("Warning: unable to open an initial console.\n"); + (void) sys_dup(0); + (void) sys_dup(0); + /* * Ok, we have completed the initial bootup, and * we're essentially up and running. Get rid of the