Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

On 01/31/2018 10:22 PM, Mimi Zohar wrote: > On Wed, 2018-01-31 at 21:03 -0500, Arvind Sankar wrote: >> On Wed, Jan 31, 2018 at 05:48:20PM -0600, Rob Landley wrote: >>> On 01/31/2018 04:07 PM, Mimi Zohar wrote: >>>> On Wed, 2018-01-31 at 13:32 -0600, Ro

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

On 02/01/2018 09:55 AM, Mimi Zohar wrote: > On Thu, 2018-02-01 at 09:20 -0600, Rob Landley wrote: > >>> With your patch and specifying "root=tmpfs", dracut is complaining: >>> >>> dracut: FATAL: Don't know how to handle 'root=tmpfs' >>>

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

On 02/01/2018 09:55 AM, Mimi Zohar wrote: > On Thu, 2018-02-01 at 09:20 -0600, Rob Landley wrote: > >>> With your patch and specifying "root=tmpfs", dracut is complaining: >>> >>> dracut: FATAL: Don't know how to handle 'root=tmpfs' >>>

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

On 01/31/2018 10:22 PM, Mimi Zohar wrote: > On Wed, 2018-01-31 at 21:03 -0500, Arvind Sankar wrote: >> On Wed, Jan 31, 2018 at 05:48:20PM -0600, Rob Landley wrote: >>> On 01/31/2018 04:07 PM, Mimi Zohar wrote: >>>> On Wed, 2018-01-31 at 13:32 -0600, Ro

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

On 01/31/2018 10:22 PM, Mimi Zohar wrote: > On Wed, 2018-01-31 at 21:03 -0500, Arvind Sankar wrote: >> On Wed, Jan 31, 2018 at 05:48:20PM -0600, Rob Landley wrote: >>> On 01/31/2018 04:07 PM, Mimi Zohar wrote: >>>> On Wed, 2018-01-31 at 13:32 -0600, Ro

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

On 01/31/2018 04:07 PM, Mimi Zohar wrote: > On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:>> (The old "I > configured in tmpfs and am using rootfs but I want that rootfs >> to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does >> it?

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

On 01/31/2018 04:07 PM, Mimi Zohar wrote: > On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:>> (The old "I > configured in tmpfs and am using rootfs but I want that rootfs >> to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does >> it?

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

G_TMPFS) && !saved_root_name[0] && - (!root_fs_names || strstr(root_fs_names, "tmpfs"))) { + if (IS_ENABLED(CONFIG_TMPFS) && (!saved_root_name[0] || + !strcmp(saved_root_name, "tmpfs"))) { err = shmem_init();

Re: [RFC PATCH] rootfs: force mounting rootfs as tmpfs

oot_name[0] && - (!root_fs_names || strstr(root_fs_names, "tmpfs"))) { + if (IS_ENABLED(CONFIG_TMPFS) && (!saved_root_name[0] || + !strcmp(saved_root_name, "tmpfs"))) { err = shmem_init(); is_tmpfs =

Allnoconfig build still broken on x86-64 in today's git.

$ make clean && make allnoconfig && make HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --allnoconfig Kconfig # # configuration written to .config # Makefile:932: *** "Cannot generate ORC

Allnoconfig build still broken on x86-64 in today's git.

$ make clean && make allnoconfig && make HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --allnoconfig Kconfig # # configuration written to .config # Makefile:932: *** "Cannot generate ORC

Re: [PATCH v2 11/15] gen_init_cpio: add newcx format

On 01/24/2018 09:27 PM, Taras Kondratiuk wrote: > diff --git a/usr/gen_init_cpio.c b/usr/gen_init_cpio.c > index 7a2a6d85345d..78a47a5bdcb1 100644 > --- a/usr/gen_init_cpio.c > +++ b/usr/gen_init_cpio.c > @@ -10,6 +10,7 @@ > #include > #include > #include > +#include You're adding an

Re: [PATCH v2 01/15] Documentation: add newcx initramfs format description

On 01/24/2018 09:27 PM, Taras Kondratiuk wrote: > diff --git a/Documentation/early-userspace/buffer-format.txt > b/Documentation/early-userspace/buffer-format.txt > index e1fd7f9dad16..d818df4f72dc 100644 > --- a/Documentation/early-userspace/buffer-format.txt > +++

Re: [PATCH v2 11/15] gen_init_cpio: add newcx format

On 01/24/2018 09:27 PM, Taras Kondratiuk wrote: > diff --git a/usr/gen_init_cpio.c b/usr/gen_init_cpio.c > index 7a2a6d85345d..78a47a5bdcb1 100644 > --- a/usr/gen_init_cpio.c > +++ b/usr/gen_init_cpio.c > @@ -10,6 +10,7 @@ > #include > #include > #include > +#include You're adding an

Re: [PATCH v2 01/15] Documentation: add newcx initramfs format description

On 01/24/2018 09:27 PM, Taras Kondratiuk wrote: > diff --git a/Documentation/early-userspace/buffer-format.txt > b/Documentation/early-userspace/buffer-format.txt > index e1fd7f9dad16..d818df4f72dc 100644 > --- a/Documentation/early-userspace/buffer-format.txt > +++

Re: [PATCH v2 01/15] Documentation: add newcx initramfs format description

On 01/25/2018 03:29 AM, Arnd Bergmann wrote: > On Thu, Jan 25, 2018 at 4:27 AM, Taras Kondratiuk wrote: >> Many of the Linux security/integrity features are dependent on file >> metadata, stored as extended attributes (xattrs), for making decisions. >> These features need to

Re: [PATCH v2 01/15] Documentation: add newcx initramfs format description

On 01/25/2018 03:29 AM, Arnd Bergmann wrote: > On Thu, Jan 25, 2018 at 4:27 AM, Taras Kondratiuk wrote: >> Many of the Linux security/integrity features are dependent on file >> metadata, stored as extended attributes (xattrs), for making decisions. >> These features need to be initialized during

Commit fc72ae40e303 broke x86-64 build environment.

You've made the ORC unwinder part of allnoconfig, which means trying to build "make ARCH=x86_64 allnoconfig" requires installing a new package (libelf-dev) or else the build breaks. What's worse, if I go into menuconfig and switch it back to frame pointer, the build STILL breaks: $ make -j 8

Commit fc72ae40e303 broke x86-64 build environment.

You've made the ORC unwinder part of allnoconfig, which means trying to build "make ARCH=x86_64 allnoconfig" requires installing a new package (libelf-dev) or else the build breaks. What's worse, if I go into menuconfig and switch it back to frame pointer, the build STILL breaks: $ make -j 8

powerpc64 kernel panic if you disable CONFIG_PPC_TRANSACTIONAL_MEM?

I just added a ppc64 target to https://github.com/landley/mkroot which means I built 4.14 with the attached miniconfig and ran it with the attached qemu command line, and it works fine as is but if you remove the transactional mem line from the config the kernel panics instead of launching a shell

powerpc64 kernel panic if you disable CONFIG_PPC_TRANSACTIONAL_MEM?

I just added a ppc64 target to https://github.com/landley/mkroot which means I built 4.14 with the attached miniconfig and ran it with the attached qemu command line, and it works fine as is but if you remove the transactional mem line from the config the kernel panics instead of launching a shell

Re: [J-core] [PATCH v5 00/22] sh: LANDISK and R2Dplus convert to device tree

On 11/17/2017 04:37 AM, John Paul Adrian Glaubitz wrote: > Hi there! > > On 07/03/2016 06:46 PM, Yoshinori Sato wrote: >> SH get devicetree support. But it not working on existing H/W. >> >> IO-DATA HDL-U (aka landisk) currentry supported. >> This H/W like SH7751 evalution board. It's a best to

Re: [J-core] [PATCH v5 00/22] sh: LANDISK and R2Dplus convert to device tree

On 11/17/2017 04:37 AM, John Paul Adrian Glaubitz wrote: > Hi there! > > On 07/03/2016 06:46 PM, Yoshinori Sato wrote: >> SH get devicetree support. But it not working on existing H/W. >> >> IO-DATA HDL-U (aka landisk) currentry supported. >> This H/W like SH7751 evalution board. It's a best to

Re: Regression: commit da029c11e6b1 broke toybox xargs.

On 11/03/2017 08:37 PM, Kees Cook wrote: > We don't. (In fact, arg copying happens before we've even figured out > which binfmt is involved.) I lifted it to just before the point of no > return, but moving it before arg copying looks very hard (which > contributed to why we went with the

Re: Regression: commit da029c11e6b1 broke toybox xargs.

On 11/03/2017 08:37 PM, Kees Cook wrote: > We don't. (In fact, arg copying happens before we've even figured out > which binfmt is involved.) I lifted it to just before the point of no > return, but moving it before arg copying looks very hard (which > contributed to why we went with the

Re: Regression: commit da029c11e6b1 broke toybox xargs.

Correcting Elliot's email to google, not gmail. (Sorry, I'm in Tokyo for work this month, almost over the jetlag...) On 11/03/2017 08:07 PM, Linus Torvalds wrote: > On Fri, Nov 3, 2017 at 4:58 PM, Rob Landley <r...@landley.net> wrote: >> On 11/02/2017 10:40 AM, Linus

Re: Regression: commit da029c11e6b1 broke toybox xargs.

Correcting Elliot's email to google, not gmail. (Sorry, I'm in Tokyo for work this month, almost over the jetlag...) On 11/03/2017 08:07 PM, Linus Torvalds wrote: > On Fri, Nov 3, 2017 at 4:58 PM, Rob Landley wrote: >> On 11/02/2017 10:40 AM, Linus Torvalds wrote: >> >> But

Re: Regression: commit da029c11e6b1 broke toybox xargs.

On 11/02/2017 10:40 AM, Linus Torvalds wrote: > On Wed, Nov 1, 2017 at 9:28 PM, Linus Torvalds > wrote: >> >> Behavior changed. Things that test particular limits will get different >> results. That's not breakage. >> >> Did an actual user application or script

Re: Regression: commit da029c11e6b1 broke toybox xargs.

On 11/02/2017 10:40 AM, Linus Torvalds wrote: > On Wed, Nov 1, 2017 at 9:28 PM, Linus Torvalds > wrote: >> >> Behavior changed. Things that test particular limits will get different >> results. That's not breakage. >> >> Did an actual user application or script break? Only due to getting the

Regression: commit da029c11e6b1 broke toybox xargs.

Toybox has been trying to figure out how big an xargs is allowed to be for a while: http://lists.landley.net/pipermail/toybox-landley.net/2017-October/009186.html We're trying to avoid the case where you can run something from the command line, but not through xargs. In theory this limit is

Regression: commit da029c11e6b1 broke toybox xargs.

Toybox has been trying to figure out how big an xargs is allowed to be for a while: http://lists.landley.net/pipermail/toybox-landley.net/2017-October/009186.html We're trying to avoid the case where you can run something from the command line, but not through xargs. In theory this limit is

[PATCH 1/1] Change ping_group_range default to what Android's init script sets.

From: Rob Landley <r...@landley.net> See message from the Android "native tools and libraries team" lead (I.E. the maintainer of bionic, adb, toolbox, etc) at http://lists.landley.net/pipermail/toybox-landley.net/2017-July/009103.html Signed-off-by: Rob Landley <r...@landley.

[PATCH 1/1] Change ping_group_range default to what Android's init script sets.

From: Rob Landley See message from the Android "native tools and libraries team" lead (I.E. the maintainer of bionic, adb, toolbox, etc) at http://lists.landley.net/pipermail/toybox-landley.net/2017-July/009103.html Signed-off-by: Rob Landley --- net/ipv4/af_inet.c |8 ++

Re: [PATCH v3] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

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 prob

Re: [PATCH v3] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

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 prob

Re: [PATCH v3] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

On 09/14/2017 04:17 AM, Christophe LEROY wrote: > Le 14/09/2017 à 01:51, Rob Landley a écrit : >> From: Rob Landley <r...@landley.net> >> >> Make initramfs honor CONFIG_DEVTMPFS_MOUNT, and move >> /dev/console open after devtmpfs mount. >> >> Add workar

Re: [PATCH v3] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

On 09/14/2017 04:17 AM, Christophe LEROY wrote: > Le 14/09/2017 à 01:51, Rob Landley a écrit : >> From: Rob Landley >> >> Make initramfs honor CONFIG_DEVTMPFS_MOUNT, and move >> /dev/console open after devtmpfs mount. >> >> Add workaround f

[PATCH v3] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

From: Rob Landley <r...@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 <r...@landley.net> --- v2 discussion: http://lkml.iu.edu/hypermail/

[PATCH v3] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

From: Rob Landley 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 --- v2 discussion: http://lkml.iu.edu/hypermail/linux/kernel/1705.2/05611.html drivers/base

Re: Patch 0727d35de ("Make initramfs honor CONFIG_DEVTMPFS_MOUNT") breaks boot

On 09/11/2017 06:45 AM, Petr Mladek wrote: >> 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()

Re: Patch 0727d35de ("Make initramfs honor CONFIG_DEVTMPFS_MOUNT") breaks boot

On 09/11/2017 06:45 AM, Petr Mladek wrote: >> 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()

Re: execve(NULL, argv, envp) for nommu?

On 09/12/2017 06:30 AM, Geert Uytterhoeven wrote: > Hi Rob, > > On Tue, Sep 12, 2017 at 12:48 PM, Rob Landley <r...@landley.net> wrote: >> Your stack has pointers. Your heap has pointers. Your data and bss (once >> initialized) can have pointers. These pointers can be

Re: execve(NULL, argv, envp) for nommu?

On 09/12/2017 06:30 AM, Geert Uytterhoeven wrote: > Hi Rob, > > On Tue, Sep 12, 2017 at 12:48 PM, Rob Landley wrote: >> Your stack has pointers. Your heap has pointers. Your data and bss (once >> initialized) can have pointers. These pointers can be in the middle of >>

Re: execve(NULL, argv, envp) for nommu?

On 09/11/2017 10:15 AM, Oleg Nesterov wrote: > On 09/08, Rob Landley wrote: >> >> So is exec(NULL, argv, envp) a reasonable thing to want? > > I think that something like prctl(PR_OPEN_EXE_FILE) which does > > dentry_open(current->mm->exe_file->path, O

Re: execve(NULL, argv, envp) for nommu?

On 09/11/2017 10:15 AM, Oleg Nesterov wrote: > On 09/08, Rob Landley wrote: >> >> So is exec(NULL, argv, envp) a reasonable thing to want? > > I think that something like prctl(PR_OPEN_EXE_FILE) which does > > dentry_open(current->mm->exe_file->path, O

Re: Patch 0727d35de ("Make initramfs honor CONFIG_DEVTMPFS_MOUNT") breaks boot

Taking another stab at this old issue from last merge window... > Rob Landley <r...@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

Re: Patch 0727d35de ("Make initramfs honor CONFIG_DEVTMPFS_MOUNT") breaks boot

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

Re: execve(NULL, argv, envp) for nommu?

On 09/05/2017 08:12 PM, Rob Landley wrote: > On 09/05/2017 08:24 AM, Alan Cox wrote: >>>> honoring the suid bit if people feel that way. I just wanna unblock >>>> vfork() while still running this code. >> >> Would it make more sense to have a way to promote

Re: execve(NULL, argv, envp) for nommu?

On 09/05/2017 08:12 PM, Rob Landley wrote: > On 09/05/2017 08:24 AM, Alan Cox wrote: >>>> honoring the suid bit if people feel that way. I just wanna unblock >>>> vfork() while still running this code. >> >> Would it make more sense to have a way to promote

Re: execve(NULL, argv, envp) for nommu?

On 09/05/2017 08:24 AM, Alan Cox wrote: >>> anymore. But I'm already _running_ this program. If I could fork() I >>> could already get a second copy of the sucker and call main() again >>> myself if necessary, but I can't, so... > > You can - ptrace 8) Oh I can call clone() with various flags

Re: execve(NULL, argv, envp) for nommu?

On 09/05/2017 08:24 AM, Alan Cox wrote: >>> anymore. But I'm already _running_ this program. If I could fork() I >>> could already get a second copy of the sucker and call main() again >>> myself if necessary, but I can't, so... > > You can - ptrace 8) Oh I can call clone() with various flags

Re: INITRAMFS_SOURCE broken by 6e19eded3684dc184181093af3bff2ff440f5b53?

On 08/08/2017 07:04 AM, Willy Tarreau wrote: > Hi Thomas, > > On Tue, Aug 08, 2017 at 01:46:25PM +0200, Thomas Meyer wrote: >> Hi, >> >> did the commit 6e19eded3684dc184181093af3bff2ff440f5b53 break a linux kernel >> build with an included ramdisk? >> >> As fas as I understand you must expliclity

Re: INITRAMFS_SOURCE broken by 6e19eded3684dc184181093af3bff2ff440f5b53?

On 08/08/2017 07:04 AM, Willy Tarreau wrote: > Hi Thomas, > > On Tue, Aug 08, 2017 at 01:46:25PM +0200, Thomas Meyer wrote: >> Hi, >> >> did the commit 6e19eded3684dc184181093af3bff2ff440f5b53 break a linux kernel >> build with an included ramdisk? >> >> As fas as I understand you must expliclity

ping/icmp sockets: define "sane".

The title is from this comment in net/ipv4: /* * Sane defaults - nobody may create ping sockets. * Boot scripts should set this to distro-specific group. */ So in 2011 you added ICMP sockets, but made it so nobody could use them without root performing a magic incatation at boot time.

ping/icmp sockets: define "sane".

The title is from this comment in net/ipv4: /* * Sane defaults - nobody may create ping sockets. * Boot scripts should set this to distro-specific group. */ So in 2011 you added ICMP sockets, but made it so nobody could use them without root performing a magic incatation at boot time.

Re: [linux-next] PPC Lpar fail to boot with error hid: module verification failed: signature and/or required key missing - tainting kernel

On 05/25/2017 04:24 PM, Stephen Rothwell wrote: > Hi Michael, > > On Thu, 25 May 2017 23:02:06 +1000 Michael Ellerman > wrote: >> >> It'll be: >> >> ee35011fd032 ("initramfs: make initramfs honor CONFIG_DEVTMPFS_MOUNT") > > And Andrew has asked me to drop that patch from

Re: [linux-next] PPC Lpar fail to boot with error hid: module verification failed: signature and/or required key missing - tainting kernel

On 05/25/2017 04:24 PM, Stephen Rothwell wrote: > Hi Michael, > > On Thu, 25 May 2017 23:02:06 +1000 Michael Ellerman > wrote: >> >> It'll be: >> >> ee35011fd032 ("initramfs: make initramfs honor CONFIG_DEVTMPFS_MOUNT") > > And Andrew has asked me to drop that patch from linux-next which will >

Re: Patch 0727d35de ("Make initramfs honor CONFIG_DEVTMPFS_MOUNT") breaks boot

On 05/23/2017 06:08 PM, Yury Norov wrote: >> It was 2 years ago, but AFAIR I took the Ubuntu image here: >> http://cdimage.ubuntu.com/ubuntu-base/releases/14.04.1/release/ubuntu-base-14.04.1-core-arm64.tar.gz Have you applied updates since then? (Maybe they fixed their init script since 2 years

Re: Patch 0727d35de ("Make initramfs honor CONFIG_DEVTMPFS_MOUNT") breaks boot

On 05/23/2017 06:08 PM, Yury Norov wrote: >> It was 2 years ago, but AFAIR I took the Ubuntu image here: >> http://cdimage.ubuntu.com/ubuntu-base/releases/14.04.1/release/ubuntu-base-14.04.1-core-arm64.tar.gz Have you applied updates since then? (Maybe they fixed their init script since 2 years

Re: Patch 0727d35de ("Make initramfs honor CONFIG_DEVTMPFS_MOUNT") breaks boot

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

Re: Patch 0727d35de ("Make initramfs honor CONFIG_DEVTMPFS_MOUNT") breaks boot

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

Re: Patch 0727d35de ("Make initramfs honor CONFIG_DEVTMPFS_MOUNT") breaks boot

On 05/22/2017 07:05 AM, Yury Norov wrote: > Hi Rob, > > I found that next-20170522 fails to boot on arm64 machine with the > following log: I don't know anything about your kernel config (is CONFIG_DEVTMPFS_MOUNT enabled or disabled?) or what userspace you're booting with, but it seems I can

Re: Patch 0727d35de ("Make initramfs honor CONFIG_DEVTMPFS_MOUNT") breaks boot

On 05/22/2017 07:05 AM, Yury Norov wrote: > Hi Rob, > > I found that next-20170522 fails to boot on arm64 machine with the > following log: I don't know anything about your kernel config (is CONFIG_DEVTMPFS_MOUNT enabled or disabled?) or what userspace you're booting with, but it seems I can

[tip:x86/urgent] x86/boot: Use CROSS_COMPILE prefix for readelf

Commit-ID: 3780578761921f094179c6289072a74b2228c602 Gitweb: http://git.kernel.org/tip/3780578761921f094179c6289072a74b2228c602 Author: Rob Landley <r...@landley.net> AuthorDate: Sat, 20 May 2017 15:03:29 -0500 Committer: Thomas Gleixner <t...@linutronix.de> CommitDate: Sun,

[tip:x86/urgent] x86/boot: Use CROSS_COMPILE prefix for readelf

Commit-ID: 3780578761921f094179c6289072a74b2228c602 Gitweb: http://git.kernel.org/tip/3780578761921f094179c6289072a74b2228c602 Author: Rob Landley AuthorDate: Sat, 20 May 2017 15:03:29 -0500 Committer: Thomas Gleixner CommitDate: Sun, 21 May 2017 13:04:27 +0200 x86/boot: Use

[PATCH] Make x86 use $TARGET-readelf like all the other arches.

From: Rob Landley <r...@landley.net> My cross-compile environment doesn't provide an unprefixed readelf in the $PATH, which works fine on every target but x86, where you get a bunch of "/bin/sh: 1: readelf: not found" messages (but the result still works anyway). Signed-off-by

[PATCH] Make x86 use $TARGET-readelf like all the other arches.

From: Rob Landley My cross-compile environment doesn't provide an unprefixed readelf in the $PATH, which works fine on every target but x86, where you get a bunch of "/bin/sh: 1: readelf: not found" messages (but the result still works anyway). Signed-off-by: Rob Landley --- arc

Re: [PATCHv2] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

On 05/16/2017 10:58 PM, Michael Ellerman wrote: > Rob Landley <r...@landley.net> writes: > >> diff --git a/init/main.c b/init/main.c >> index f866510..9ec09ff 100644 >> --- a/init/main.c >> +++ b/init/main.c >> @@ -1055,8 +1049,17 @@ static noin

Re: [PATCHv2] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

On 05/16/2017 10:58 PM, Michael Ellerman wrote: > Rob Landley writes: > >> diff --git a/init/main.c b/init/main.c >> index f866510..9ec09ff 100644 >> --- a/init/main.c >> +++ b/init/main.c >> @@ -1055,8 +1049,17 @@ static noinline void __init kernel_init_f

Re: [PATCHv2] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

Andrew asked for "a more complete changelog" and I've had a reply window open for _days_ trying to figure out what he wants. Maybe it's in the following somewhere... Otherwise the same v2 patch. From: Rob Landley <r...@landley.net> Make initramfs honor CONFIG_DEVTMPFS_MOUN

Re: [PATCHv2] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

Andrew asked for "a more complete changelog" and I've had a reply window open for _days_ trying to figure out what he wants. Maybe it's in the following somewhere... Otherwise the same v2 patch. From: Rob Landley Make initramfs honor CONFIG_DEVTMPFS_MOUNT (fixing commit 2b2af54a

Re: Is there an recommended way to refer to bitkeepr commits?

On 05/12/2017 12:49 PM, Andreas Schwab wrote: > On Mai 12 2017, Rob Landley <r...@landley.net> wrote: > >> Last I checked I couldn't just "git push" the fullhist tree to >> git.kernel.org because git graft didn't propagate right. > > Perhaps you coul

Re: Is there an recommended way to refer to bitkeepr commits?

On 05/12/2017 12:49 PM, Andreas Schwab wrote: > On Mai 12 2017, Rob Landley wrote: > >> Last I checked I couldn't just "git push" the fullhist tree to >> git.kernel.org because git graft didn't propagate right. > > Perhaps you could recreate them with

Re: Is there an recommended way to refer to bitkeepr commits?

On 05/13/2017 04:35 AM, Thomas Gleixner wrote: > On Fri, 12 May 2017, Eric W. Biederman wrote: >> Which leaves me perplexed. The hashes from tglx's current tree: >> https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git >> on kernel.org and the hashes in your full history tree differ.

Re: Is there an recommended way to refer to bitkeepr commits?

On 05/13/2017 04:35 AM, Thomas Gleixner wrote: > On Fri, 12 May 2017, Eric W. Biederman wrote: >> Which leaves me perplexed. The hashes from tglx's current tree: >> https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git >> on kernel.org and the hashes in your full history tree differ.

Re: Is there an recommended way to refer to bitkeepr commits?

On 05/12/2017 09:45 AM, Eric W. Biederman wrote: > Thomas Gleixner writes: > >> On Fri, 12 May 2017, Michael Ellerman wrote: >>> Fixes: BKrev: 3e8e57a1JvR25MkFRNzoz85l2Gzccg ("[PATCH] >>> linux-2.5.66-signal-cleanup.patch") >>> >>> In your tree that is c3c107051660

Re: Is there an recommended way to refer to bitkeepr commits?

On 05/12/2017 09:45 AM, Eric W. Biederman wrote: > Thomas Gleixner writes: > >> On Fri, 12 May 2017, Michael Ellerman wrote: >>> Fixes: BKrev: 3e8e57a1JvR25MkFRNzoz85l2Gzccg ("[PATCH] >>> linux-2.5.66-signal-cleanup.patch") >>> >>> In your tree that is c3c107051660 ("[PATCH] >>>

[PATCHv2] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

From: Rob Landley <r...@landley.net> Make initramfs honor CONFIG_DEVTMPFS_MOUNT, move /dev/console open after devtmpfs mount, and update help text. Signed-off-by: Rob Landley <r...@landley.net> --- drivers/base/Kconfig | 14 -- init/main.c | 15 +---

[PATCHv2] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

From: Rob Landley Make initramfs honor CONFIG_DEVTMPFS_MOUNT, move /dev/console open after devtmpfs mount, and update help text. Signed-off-by: Rob Landley --- drivers/base/Kconfig | 14 -- init/main.c | 15 +-- 2 files changed, 13 insertions(+), 16

Re: [PATCH] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

On 05/09/2017 04:31 PM, Andrew Morton wrote: > On Thu, 4 May 2017 16:09:06 -0500 Rob Landley <r...@landley.net> wrote: > >> From: Rob Landley <r...@landley.net> >> >> Make initramfs honor CONFIG_DEVTMPFS_MOUNT, and move >> /dev/console open after d

Re: [PATCH] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

On 05/09/2017 04:31 PM, Andrew Morton wrote: > On Thu, 4 May 2017 16:09:06 -0500 Rob Landley wrote: > >> From: Rob Landley >> >> Make initramfs honor CONFIG_DEVTMPFS_MOUNT, and move >> /dev/console open after devtmpfs mount. > > > Could we please

Re: Is there an recommended way to refer to bitkeepr commits?

a tree with all of those same commits >>> except with the BKrev tags stripped out. >> >> That's the best import - so use that tree by Thomas, and just use the >> git revision numbers in it (and say "tglx's linux-history tree" or >> something). > > I've been

Re: Is there an recommended way to refer to bitkeepr commits?

ripped out. >> >> That's the best import - so use that tree by Thomas, and just use the >> git revision numbers in it (and say "tglx's linux-history tree" or >> something). > > I've been using this one by Rob Landley which seems good: > > htt

[PATCH] Clarify help text that compression applies to ramfs as well as legacy ramdisk.

From: Rob Landley <r...@landley.net> Clarify help text that compression applies to ramfs as well as legacy ramdisk. Signed-off-by: Rob Landley <r...@landley.net> --- usr/Kconfig | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/usr/Kconfig b/usr/K

[PATCH] Clarify help text that compression applies to ramfs as well as legacy ramdisk.

From: Rob Landley Clarify help text that compression applies to ramfs as well as legacy ramdisk. Signed-off-by: Rob Landley --- usr/Kconfig | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/usr/Kconfig b/usr/Kconfig index 572dcf7..d6f4633 100644 --- a/usr

[PATCH] Teach INITRAMFS_ROOT_UID and INITRAMFS_ROOT_GID that -1 means "current user".

From: Rob Landley <r...@landley.net> Teach INITRAMFS_ROOT_UID and INITRAMFS_ROOT_GID that -1 means "current user". Signed-off-by: Rob Landley <r...@landley.net> --- scripts/gen_initramfs_list.sh |2 ++ usr/Kconfig | 12 2 files chang

[PATCH] Teach INITRAMFS_ROOT_UID and INITRAMFS_ROOT_GID that -1 means "current user".

From: Rob Landley Teach INITRAMFS_ROOT_UID and INITRAMFS_ROOT_GID that -1 means "current user". Signed-off-by: Rob Landley --- scripts/gen_initramfs_list.sh |2 ++ usr/Kconfig | 12 2 files changed, 6 insertions(+), 8 deletions(-) diff --git

[PATCH] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

From: Rob Landley <r...@landley.net> Make initramfs honor CONFIG_DEVTMPFS_MOUNT, and move /dev/console open after devtmpfs mount. Signed-off-by: Rob Landley <r...@landley.net> --- init/main.c | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/i

[PATCH] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

From: Rob Landley Make initramfs honor CONFIG_DEVTMPFS_MOUNT, and move /dev/console open after devtmpfs mount. Signed-off-by: Rob Landley --- init/main.c | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/init/main.c b/init/main.c index 2858be7..71ed0d7

Re: [PATCH 1/3] futex: remove duplicated code

On 03/04/2017 07:05 AM, Russell King - ARM Linux wrote: > On Fri, Mar 03, 2017 at 01:27:10PM +0100, Jiri Slaby wrote: >> diff --git a/kernel/futex.c b/kernel/futex.c >> index b687cb22301c..c5ff9850952f 100644 >> --- a/kernel/futex.c >> +++ b/kernel/futex.c >> @@ -1457,6 +1457,42 @@ futex_wake(u32

Re: [PATCH 1/3] futex: remove duplicated code

On 03/04/2017 07:05 AM, Russell King - ARM Linux wrote: > On Fri, Mar 03, 2017 at 01:27:10PM +0100, Jiri Slaby wrote: >> diff --git a/kernel/futex.c b/kernel/futex.c >> index b687cb22301c..c5ff9850952f 100644 >> --- a/kernel/futex.c >> +++ b/kernel/futex.c >> @@ -1457,6 +1457,42 @@ futex_wake(u32

Re: Runtime failure running sh:qemu in -next due to 'sh: fix copy_from_user()'

On 09/18/2016 10:17 AM, Rich Felker wrote: > On Sat, Sep 17, 2016 at 11:40:28PM -0500, Rob Landley wrote: >> >> >> On 09/16/2016 09:23 PM, Guenter Roeck wrote: >>> On 09/16/2016 04:32 PM, Rich Felker wrote: >>>>> 4.6.3 from kernel.org. >>>&g

Re: Runtime failure running sh:qemu in -next due to 'sh: fix copy_from_user()'

On 09/18/2016 10:17 AM, Rich Felker wrote: > On Sat, Sep 17, 2016 at 11:40:28PM -0500, Rob Landley wrote: >> >> >> On 09/16/2016 09:23 PM, Guenter Roeck wrote: >>> On 09/16/2016 04:32 PM, Rich Felker wrote: >>>>> 4.6.3 from kernel.org. >>>&g

Re: Runtime failure running sh:qemu in -next due to 'sh: fix copy_from_user()'

On 09/16/2016 09:23 PM, Guenter Roeck wrote: > On 09/16/2016 04:32 PM, Rich Felker wrote: >>> 4.6.3 from kernel.org. >> >> That is utterly ancient and probaby very buggy. I would recommend 5.x+ >> or at the very least 4.7 or 4.8. >> > Unfortunately that is the latest one available from

Re: Runtime failure running sh:qemu in -next due to 'sh: fix copy_from_user()'

On 09/16/2016 09:23 PM, Guenter Roeck wrote: > On 09/16/2016 04:32 PM, Rich Felker wrote: >>> 4.6.3 from kernel.org. >> >> That is utterly ancient and probaby very buggy. I would recommend 5.x+ >> or at the very least 4.7 or 4.8. >> > Unfortunately that is the latest one available from

Re: [RFC] fs: add userspace critical mounts event support

On 09/02/2016 07:20 PM, Luis R. Rodriguez wrote: > kernel_read_file_from_path() can try to read a file from > the system's filesystem. This is typically done for firmware > for instance, which lives in /lib/firmware. One issue with > this is that the kernel cannot know for sure when the real >

Re: [RFC] fs: add userspace critical mounts event support

On 09/02/2016 07:20 PM, Luis R. Rodriguez wrote: > kernel_read_file_from_path() can try to read a file from > the system's filesystem. This is typically done for firmware > for instance, which lives in /lib/firmware. One issue with > this is that the kernel cannot know for sure when the real >

Re: [PATCH] sh: Fix building j2_defconfig

On 08/16/2016 04:23 PM, Jason Cooper wrote: > Hi Rob, > > On Tue, Aug 16, 2016 at 04:15:22PM -0500, Rob Landley wrote: >> On 08/16/2016 10:41 AM, Jason Cooper wrote: >>> When targeting the j2, we need to retain '-m2'. Previously, the >>> Makefile blew out -m2 on

Re: [PATCH] sh: Fix building j2_defconfig

On 08/16/2016 04:23 PM, Jason Cooper wrote: > Hi Rob, > > On Tue, Aug 16, 2016 at 04:15:22PM -0500, Rob Landley wrote: >> On 08/16/2016 10:41 AM, Jason Cooper wrote: >>> When targeting the j2, we need to retain '-m2'. Previously, the >>> Makefile blew out -m2 on

Re: [PATCH] sh: Fix building j2_defconfig

On 08/16/2016 10:41 AM, Jason Cooper wrote: > When targeting the j2, we need to retain '-m2'. Previously, the > Makefile blew out -m2 on the next line via :=. > > Fix this by s/:=/+=/ when building for the J2. > > Fixes: 5a846abad07f6 ("sh: add support for J-Core J2 processor") > Signed-off-by:

<    1   2   3   4   5   6   7   8   9   10   >