Re: Old platforms never die, was Re: Old platforms: bring out your dead

On 1/12/21 6:12 PM, Finn Thain wrote: > If you're a museum interested in cultural artifacts from decades past, or > if you're a business doing data recovery, you're going to need to operate > those platforms. Or if you're camping patent expirations and want to be able to point at prior art for

Re: Old platforms: bring out your dead

On 1/13/21 2:21 AM, Geert Uytterhoeven wrote: > Hi Rob, > > On Wed, Jan 13, 2021 at 8:58 AM Rob Landley wrote: >> On 1/12/21 4:46 PM, Linus Walleij wrote: >>> On Tue, Jan 12, 2021 at 3:45 PM John Paul Adrian Glaubitz >>> wrote: >>>> Yeah, I have the

Re: Old platforms: bring out your dead

On 1/12/21 4:46 PM, Linus Walleij wrote: > On Tue, Jan 12, 2021 at 3:45 PM John Paul Adrian Glaubitz > wrote: > >> Yeah, I have the same impression that's the strong commercial interest pushes >> hobbyist use of the Linux kernel a bit down. A lot of these changes feel like >> they're motivated

Re: Old platforms: bring out your dead

On 1/11/21 8:55 AM, chase rayfield wrote: > On Mon, Jan 11, 2021 at 3:09 AM John Paul Adrian Glaubitz > wrote: > >> >> I'm not sure I understand the reasoning for doing this. The SPARC >> architecture >> isn't going to see any new hardware developments in the future after Oracle >> let go of

Re: Old platforms: bring out your dead

On 1/10/21 3:46 PM, Sam Ravnborg wrote: > Hi all, >> Hi Arnd! >> >> (Please let's have this cross-posted for more visibility. I only learned >> about this >> while reading Phoronix news) >> >>> I also looked at non-ARM platforms while preparing for my article. Some of >>> these look like they

Re: ac0e958a00: Kernel_panic-not_syncing:stack-protector:Kernel_stack_is_corrupted_in:run_init_process

On 11/12/20 7:49 AM, David Laight wrote: > From: Rob Landley >> Sent: 12 November 2020 12:46 >> >> On 11/12/20 1:11 AM, kernel test robot wrote: >>> >>> Greeting, >>> >>> FYI, we noticed the following commit (built with gcc-9): >> >

Re: ac0e958a00: Kernel_panic-not_syncing:stack-protector:Kernel_stack_is_corrupted_in:run_init_process

space before the tail call, and I'd assume exec restarts the stack anyway.) Second-attempt-by: Rob Landley --- init/main.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/init/main.c b/init/main.c index 130376ec10ba..e92320816ef8 100644 --- a/init/main.c +++ b

[PATCH] Collate "run init" message to one line with prefixed var assignments

From: Rob Landley Run init: HOME=/ TERM=linux /init Signed-off-by: Rob Landley --- init/main.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/init/main.c b/init/main.c index 130376ec10ba..80b06566852b 100644 --- a/init/main.c +++ b/init/main.c

[PATCH] switch "random: fast init done" message from NOTICE to INFO.

From: Rob Landley If you loglevel=4 you get zero kernel boot messages, but at loglevel=5 the shell prompt is overwritten on devices that boot to a serial console a second after it comes up, and if the prompt is "#" it's easy to think the boot's hung. Signed-off-by: Rob Landley ---

Re: [PATCH] sh: fix syscall tracing

On 9/10/20 4:55 AM, John Paul Adrian Glaubitz wrote: > Hi Rich! > > On 9/7/20 7:44 PM, Rich Felker wrote: >>> Can we still get this merged as a hotfix for 5.9? >> >> Yes, fixes for regressions in the same release cycle are in-scope (the >> whole point of having -rc's). I have at least one other

Re: [PATCH] serial: sh-sci: Make sure status register SCxSR is read in correct sequence

On 8/16/20 11:22 AM, Prabhakar Mahadev Lad wrote: >> FTR, I gave it a try on the SH7751R-based I-O DATA USL-5P aka Landisk: >> SCIF is affected, and fixed by commit 3dc4db3662366306 ("serial: sh-sci: >> Make sure status register SCxSR is read in correct sequence"). >> > Thank you Geert. > >

Re: [PATCH] sh: Replace HTTP links with HTTPS ones

return 200 OK and serve the same content: > Replace HTTP with HTTPS. > > Signed-off-by: Alexander A. Klimov Acked-by: Rob Landley Rob

Re: [PATCH] SUPERH: Replace HTTP links with HTTPS ones

On 7/8/20 9:17 PM, Alexander A. Klimov wrote: > diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig > index 9fc2b010e938..bc91bdb0b665 100644 > --- a/arch/sh/Kconfig > +++ b/arch/sh/Kconfig > @@ -74,7 +74,7 @@ config SUPERH > The SuperH is a RISC processor targeted for use in embedded systems >

Re: [PATCH 09/10] sh: don't allow non-coherent DMA for NOMMU

On 6/26/20 3:07 AM, Christoph Hellwig wrote: > The code handling non-coherent DMA depends on being able to remap code > as non-cached. But that can't be done without an MMU, so using this > option on NOMMU builds is broken. I'm working on a nommu j-core board that's doing DMA behind the OS's

headers_install builds break on a lot of targets?

The headers_install_all target got removed last year (commit f3c8d4c7a728 and would someone like to update Documentation/kbuild/headers_install.txt which still describes it?) The musl-libc maintainer is using a forked hand-hacked kernel header package in his toolchain build project

Re: [GIT PULL] sh: remove sh5 support

On 5/30/20 3:08 AM, John Paul Adrian Glaubitz wrote: > On 5/29/20 7:53 PM, Rich Felker wrote: >> Frustratingly, I _still_ don't have an official tree on kernel.org for >> the purpose of being the canonical place for linux-next to pull from, >> due to policies around pgp keys and nobody following

Re: [GIT PULL] sh: remove sh5 support

On 5/28/20 5:14 PM, Rich Felker wrote: > Aside from that, the open source & open hardware J-core models are > still active and in development, with the latest release having been > made this month, and the J32 with MMU nearly complete and pending > release, contingent mostly on integration and

Re: [GIT PULL] sh: remove sh5 support

On 5/28/20 12:55 AM, John Paul Adrian Glaubitz wrote: > On 5/28/20 7:46 AM, Christoph Hellwig wrote: >> [adding Linus] >> >> On Thu, May 07, 2020 at 07:35:52AM -0700, Christoph Hellwig wrote: >>> Any progress on this? I plan to resend the sh dma-mapping I've been >>> trying to get upstream for a

Re: [PATCH v2 7/8] exec: Generic execfd support

On 5/21/20 10:28 PM, Eric W. Biederman wrote: > > Rob Landley writes: > >> On 5/20/20 11:05 AM, Eric W. Biederman wrote: > >> Toybox would _like_ proc mounted, but can't assume it. I'm writing a new >> bash-compatible shell with nommu support, which

Re: [PATCH v2 7/8] exec: Generic execfd support

On 5/20/20 11:05 AM, Eric W. Biederman wrote: > Rob Landley writes: > >> On 5/18/20 7:33 PM, Eric W. Biederman wrote: >>> >>> Most of the support for passing the file descriptor of an executable >>> to an interpreter already lives in the generic code a

Re: [PATCH v2 7/8] exec: Generic execfd support

On 5/18/20 7:33 PM, Eric W. Biederman wrote: > > Most of the support for passing the file descriptor of an executable > to an interpreter already lives in the generic code and in binfmt_elf. > Rework the fields in binfmt_elf that deal with executable file > descriptor passing to make executable

Re: [PATCH v4] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

On 5/14/20 11:50 PM, Randy Dunlap wrote: > Hi Rob, Um, hi. > You need to send this patch to some maintainer who could merge it. The implicit "if" is "you expect the kernel bureaucracy to merge anything Not Invented Here", and the 3 year gap since the last version is because I stopped:

[PATCH v4] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

FYI I dug up my old https://lkml.org/lkml/2017/9/13/651 and ported it to current, because I needed it for a thing. 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

Re: [PATCH 3/5] exec: Remove recursion from search_binary_handler

On 5/13/20 4:59 PM, Eric W. Biederman wrote: > Careful with your terminology. ELF sections are for .o's For > executables ELF have segments. And reading through the code it is the > program segments that are independently relocatable. Sorry, I have trouble keeping this stuff straight when it's

Re: [PATCH 3/5] exec: Remove recursion from search_binary_handler

On 5/12/20 7:20 PM, Linus Torvalds wrote: > On Tue, May 12, 2020 at 11:46 AM Eric W. Biederman > wrote: >> >> I am still thinking about this one, but here is where I am at. At a >> practical level passing the file descriptor of the script to interpreter >> seems like something we should

Re: [PATCH 3/5] exec: Remove recursion from search_binary_handler

On 5/11/20 9:33 AM, Eric W. Biederman wrote: > What I do see is that interp_data is just a parameter that is smuggled > into the call of search binary handler. And the next binary handler > needs to be binfmt_elf for it to make much sense, as only binfmt_elf > (and binfmt_elf_fdpic) deals with

Re: [PATCH v2 0/5] Fix ELF / FDPIC ELF core dumping, and use mmap_sem properly in there

On 5/1/20 1:00 AM, Greg Ungerer wrote: >> This sounds correct. My understanding of FLAT shared library support >> is that it's really bad and based on having preassigned slot indices >> for each library on the system, and a global array per-process to give >> to data base address for each library.

Re: [PATCH v2 0/5] Fix ELF / FDPIC ELF core dumping, and use mmap_sem properly in there

On 4/30/20 9:51 AM, Rich Felker wrote: > This sounds correct. My understanding of FLAT shared library support > is that it's really bad and based on having preassigned slot indices > for each library on the system, and a global array per-process to give > to data base address for each library.

Re: [PATCH 2/5] coredump: Fix handling of partial writes in dump_emit()

On 4/27/20 10:35 PM, Linus Torvalds wrote: > On Mon, Apr 27, 2020 at 8:28 PM Jann Horn wrote: >> >> After a partial write, we have to update the input buffer pointer. > > Interesting. It seems this partial write case never triggers (except > for actually killing the core-dump). > > Or did you

Re: [PATCH v2 7/7] n_tty: Provide an informational line on VSTATUS receipt

On 8/1/19 4:20 AM, Greg Kroah-Hartman wrote: >> SysRq is system-wide, whereas this is per-terminal and only cares about >> one tty which the status char is pressed at and its foreground pgrp >> (most likely it's the foreground shell job). >> >> I hope this is clear enough. > > It is, yes. My big

Re: [PATCH v2 7/7] n_tty: Provide an informational line on VSTATUS receipt

On 7/30/19 11:19 AM, Greg Kroah-Hartman wrote: > On Tue, Jun 25, 2019 at 07:11:53PM +0300, Arseny Maslennikov wrote: >> If the three termios local flags isig, icanon, iexten are enabled >> and the local flag nokerninfo is disabled for a tty governed >> by the n_tty line discipline, then on

Re: [PATCH 0/7] TTY Keyboard Status Request

On 6/9/19 3:56 PM, Arseny Maslennikov wrote: > This is similar to SIGWINCH, which is default-ignored as well: if the > terminal width/height changes (like when a terminal emulator window is > resized), its foreground pgrp gets a surprise signal as well, and the > processes that don't care about

Re: [PATCH 1/7] signal.h: Define SIGINFO on all architectures

On 6/5/19 3:19 AM, Arseny Maslennikov wrote: > This complementary patch defines SIGINFO as a synonym for SIGPWR > on every architecture supported by the kernel. > The particular signal number chosen does not really matter and is only > required for the related tty functionality to work properly, >

Re: [PATCH 0/7] TTY Keyboard Status Request

On 6/5/19 3:18 AM, Arseny Maslennikov wrote: > This patch series introduces TTY keyboard status request, a feature of > the n_tty line discipline that reserves a character in struct termios > (^T by default) and reacts to it by printing a short informational line > to the terminal and sending a

Re: [PATCH v3 2/2] initramfs: introduce do_readxattrs()

On 5/22/19 11:17 AM, h...@zytor.com wrote: > On May 20, 2019 2:39:46 AM PDT, Roberto Sassu > wrote: >> On 5/18/2019 12:17 AM, Arvind Sankar wrote: >>> On Fri, May 17, 2019 at 02:47:31PM -0700, H. Peter Anvin wrote: On 5/17/19 2:02 PM, Arvind Sankar wrote: > On Fri, May 17, 2019 at

Re: [PATCH v3 2/2] initramfs: introduce do_readxattrs()

On 5/17/19 4:41 PM, H. Peter Anvin wrote: > On 5/17/19 1:18 PM, h...@zytor.com wrote: >> >> Ok... I just realized this does not work for a modular initramfs, composed >> at load time from multiple files, which is a very real problem. Should be >> easy enough to deal with: instead of one large

Re: [PATCH v3 2/2] initramfs: introduce do_readxattrs()

On 5/17/19 3:18 PM, h...@zytor.com wrote: > Ok... I just realized this does not work for a modular initramfs, composed at > load time from multiple files, which is a very real problem. Should be easy > enough to deal with: instead of one large file, use one companion file per > source file,

Re: [PATCH v2 0/3] initramfs: add support for xattrs in the initial ram disk

On 5/14/19 2:18 PM, James Bottomley wrote: >> I think Rob is right here. If /init was statically built into the >> kernel image, it has no more ability to compromise the kernel than >> anything else in the kernel. What's the problem here? > > The specific problem is that unless you own the

Re: [PATCH v2 0/3] initramfs: add support for xattrs in the initial ram disk

On 5/14/19 6:52 AM, Roberto Sassu wrote: > On 5/14/2019 8:06 AM, Rob Landley wrote: >> On 5/13/19 7:47 AM, Roberto Sassu wrote: >>> On 5/13/2019 11:07 AM, Rob Landley wrote: >>>>>> Wouldn't the below work even before enforcing signatures on external >>&g

Re: [PATCH v2 0/3] initramfs: add support for xattrs in the initial ram disk

On 5/13/19 5:09 PM, Mimi Zohar wrote: >> Ok, but wouldn't my idea still work? Leave the default compiled-in >> policy set to not appraise initramfs. The embedded /init sets all the >> xattrs, changes the policy to appraise tmpfs, and then exec's the real >> init? Then everything except the

Re: [PATCH v2 0/3] initramfs: add support for xattrs in the initial ram disk

On 5/13/19 7:47 AM, Roberto Sassu wrote: > On 5/13/2019 11:07 AM, Rob Landley wrote: >>>> Wouldn't the below work even before enforcing signatures on external >>>> initramfs: >>>> 1. Create an embedded initramfs with an /init that does the xattr >>>

Re: [PATCH v2 0/3] initramfs: add support for xattrs in the initial ram disk

On 5/13/19 2:49 AM, Roberto Sassu wrote: > On 5/12/2019 9:43 PM, Arvind Sankar wrote: >> On Sun, May 12, 2019 at 05:05:48PM +0000, Rob Landley wrote: >>> On 5/12/19 7:52 AM, Mimi Zohar wrote: >>>> On Sun, 2019-05-12 at 11:17 +0200, Dominik Brodowski wrote: >&

Re: [PATCH v2 0/3] initramfs: add support for xattrs in the initial ram disk

On 5/12/19 7:52 AM, Mimi Zohar wrote: > On Sun, 2019-05-12 at 11:17 +0200, Dominik Brodowski wrote: >> On Thu, May 09, 2019 at 01:24:17PM +0200, Roberto Sassu wrote: >>> This proposal consists in marshaling pathnames and xattrs in a file called >>> .xattr-list. They are unmarshaled by the CPIO

Re: [PATCH v2 0/3] initramfs: add support for xattrs in the initial ram disk

On 5/11/19 11:04 PM, Rob Landley wrote: > P.P.S. Sadly, if you want an actually standardized standard format where > implementations adhere to the standard: IETF RFC 1991 was published in 1996 > and Nope, darn it, checked my notes and that wasn't it. I thought zip had an RFC, it's

Re: [PATCH v2 0/3] initramfs: add support for xattrs in the initial ram disk

On 5/11/19 5:44 PM, Andy Lutomirski wrote: > I read some of those emails. ISTM that adding TAR support should be > seriously considered. Sure, it's baroque, but it's very, very well > supported, and it does exactly what we need. Which means you now have two parsers supported in parallel

Re: [PATCH v2 0/3] initramfs: add support for xattrs in the initial ram disk

On 5/10/19 6:49 AM, Mimi Zohar wrote: > On Fri, 2019-05-10 at 08:56 +0200, Roberto Sassu wrote: >> On 5/9/2019 8:34 PM, Rob Landley wrote: >>> On 5/9/19 6:24 AM, Roberto Sassu wrote: > >>>> The difference with another proposal >>>> (https://lore.kerne

Re: [PATCH v2 0/3] initramfs: add support for xattrs in the initial ram disk

On 5/9/19 6:24 AM, Roberto Sassu wrote: > This patch set aims at solving the following use case: appraise files from > the initial ram disk. To do that, IMA checks the signature/hash from the > security.ima xattr. Unfortunately, this use case cannot be implemented > currently, as the CPIO format

Re: Commit 594cc251fdd0 (user_access_begin does access_ok) made arch/sh stop booting on qemu.

On 1/31/19 2:30 AM, Linus Torvalds wrote: > See > >   >    > https://lore.kernel.org/lkml/CAHk-=wihe4dnhkpe4oghwwmy23jntuufqagwtgcjjxyovyj...@mail.gmail.com/ > > for an explanation of the SH bug. > > But Guenter Roeck confirmed that my patch fixed it on SH for him. Is there > something else

Commit 594cc251fdd0 (user_access_begin does access_ok) made arch/sh stop booting on qemu.

That's what I bisected it to, anyway. Commit before that boots to a shell prompt under qemu-system-sh4 (built from today's git), after produces no console output (no boot messages, no nothin'). Rob # make ARCH=sh allnoconfig KCONFIG_ALLCONFIG=sh4.miniconf # make ARCH=sh -j $(nproc) # boot

Re: [PATCH 2/2] sh: generate uapi header and syscall table header files

On 1/10/19 5:54 PM, Guenter Roeck wrote: > On Wed, Jan 02, 2019 at 09:07:25PM +0530, Firoz Khan wrote: >> Unified system call table generation script must be run to >> generate unistd_32.h and syscall_table.h files. This patch >> will have changes which will invokes the script. >> >> This patch

Re: dma_declare_coherent_memory on main memory

On 12/7/18 9:34 AM, Christoph Hellwig wrote: > Hi all, > > the ARM imx27/31 ports and various sh boards use > dma_declare_coherent_memory on main memory taken from the memblock > allocator. > > Is there any good reason these couldn't be switched to CMA areas? > Getting rid of these magic

Re: [RFC][PATCH] fs: set xattrs in initramfs from regular files

On 11/26/18 6:56 AM, Roberto Sassu wrote: > On 11/23/2018 9:21 PM, Rob Landley wrote: >>> The aim of this patch is to provide the same functionality without >>> introducing a new format. The value of xattrs is placed in regular files >>> having the same file name

Re: [RFC][PATCH] fs: set xattrs in initramfs from regular files

On 11/26/18 6:56 AM, Roberto Sassu wrote: > On 11/23/2018 9:21 PM, Rob Landley wrote: >>> The aim of this patch is to provide the same functionality without >>> introducing a new format. The value of xattrs is placed in regular files >>> having the same file name

Re: [RFC][PATCH] fs: set xattrs in initramfs from regular files

On 11/22/18 9:49 AM, Roberto Sassu wrote: > Although rootfs (tmpfs) supports xattrs, they are not set due to the > limitation of the cpio format. A new format called 'newcx' was proposed to > overcome this limitation. I got email about that format the day before you posted this, by the way. >

Re: [RFC][PATCH] fs: set xattrs in initramfs from regular files

On 11/22/18 9:49 AM, Roberto Sassu wrote: > Although rootfs (tmpfs) supports xattrs, they are not set due to the > limitation of the cpio format. A new format called 'newcx' was proposed to > overcome this limitation. I got email about that format the day before you posted this, by the way. >

Re: [PATCH v3 0/3] sh: system call table generation support

On 11/19/18 2:08 AM, Geert Uytterhoeven wrote: > On Mon, Nov 19, 2018 at 6:26 AM Rob Landley wrote: >> WARNING: CPU: 0 PID: 1 at mm/slub.c:2448 >> ___slab_alloc.constprop.34+0x196/0x288 > > https://patchwork.kernel.org/patch/10549883/ Given that Sato-san is co-

Re: [PATCH v3 0/3] sh: system call table generation support

On 11/19/18 2:08 AM, Geert Uytterhoeven wrote: > On Mon, Nov 19, 2018 at 6:26 AM Rob Landley wrote: >> WARNING: CPU: 0 PID: 1 at mm/slub.c:2448 >> ___slab_alloc.constprop.34+0x196/0x288 > > https://patchwork.kernel.org/patch/10549883/ Given that Sato-san is co-

Re: [PATCH v3 0/3] sh: system call table generation support

eration support implementation > across all the architectures. I applied the patch in https://github.com/landley/mkroot and the result booted under qemu-system-sh4, seems to work fine. Network's fine, it can read a block device, etc. Acked-and-or-tested-by: Rob Landley I assume that this i

Re: [PATCH v3 0/3] sh: system call table generation support

eration support implementation > across all the architectures. I applied the patch in https://github.com/landley/mkroot and the result booted under qemu-system-sh4, seems to work fine. Network's fine, it can read a block device, etc. Acked-and-or-tested-by: Rob Landley I assume that this i

The CONFIG_UNWINDER_ORC bug is back.

Do "make defconfig" on x86-64, fire up menuconfig and select the frame pointer uwinder (under kernel hacking -> choose unwinder) and: $ make Makefile:966: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel". Stop.

The CONFIG_UNWINDER_ORC bug is back.

Do "make defconfig" on x86-64, fire up menuconfig and select the frame pointer uwinder (under kernel hacking -> choose unwinder) and: $ make Makefile:966: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel". Stop.

devinet.c inet_abc_len() breaking ifconfig?

Dave Taht pointed out to me that this doesn't work in toybox: $ ifconfig eth0 242.2.0.1 netmask 255.255.255.0 broadcast 242.2.0.255 ifconfig: ioctl 8916: Invalid argument Because of this in the kernel:

devinet.c inet_abc_len() breaking ifconfig?

Dave Taht pointed out to me that this doesn't work in toybox: $ ifconfig eth0 242.2.0.1 netmask 255.255.255.0 broadcast 242.2.0.255 ifconfig: ioctl 8916: Invalid argument Because of this in the kernel:

Re: [RESEND PATCH] init/Kconfig: Use short unix-style option instead of --longname

On 08/07/2018 11:06 PM, Masahiro Yamada wrote: > From: Rob Landley > > Avoids warning messages with the latest release of toybox, which never > bothered to implement the --longopts nothing was using. > > Signed-off-by: Rob Landley > Signed-off-by: Masahiro Yamada >

Re: [RESEND PATCH] init/Kconfig: Use short unix-style option instead of --longname

On 08/07/2018 11:06 PM, Masahiro Yamada wrote: > From: Rob Landley > > Avoids warning messages with the latest release of toybox, which never > bothered to implement the --longopts nothing was using. > > Signed-off-by: Rob Landley > Signed-off-by: Masahiro Yamada >

Re: [PATCH] Fix platform data in leds-pca955x.c

On 07/04/2018 12:04 PM, Andy Shevchenko wrote: > On Wed, Jul 4, 2018 at 8:00 PM, Andy Shevchenko > wrote: >> On Wed, Jul 4, 2018 at 3:46 AM, Rob Landley wrote: > >> For now, you can switch to unified device properties API (basically >> un-ifdef pca955x_pdata_

Re: [PATCH] Fix platform data in leds-pca955x.c

On 07/04/2018 12:04 PM, Andy Shevchenko wrote: > On Wed, Jul 4, 2018 at 8:00 PM, Andy Shevchenko > wrote: >> On Wed, Jul 4, 2018 at 3:46 AM, Rob Landley wrote: > >> For now, you can switch to unified device properties API (basically >> un-ifdef pca955x_pdata_

Re: [PATCH] Fix platform data in leds-pca955x.c

On 07/04/2018 12:00 PM, Andy Shevchenko wrote: > On Wed, Jul 4, 2018 at 3:46 AM, Rob Landley wrote: >> I have some questions about recent changes to leds-pca955x.c since 4.13: >> >> How is non-of platform data supposed to work now? Commit ed1f4b9676a8 >> switched

Re: [PATCH] Fix platform data in leds-pca955x.c

On 07/04/2018 12:00 PM, Andy Shevchenko wrote: > On Wed, Jul 4, 2018 at 3:46 AM, Rob Landley wrote: >> I have some questions about recent changes to leds-pca955x.c since 4.13: >> >> How is non-of platform data supposed to work now? Commit ed1f4b9676a8 >> switched

[PATCH] Fix platform data in leds-pca955x.c

t_trigger pointing to external memory. Is there a reason this is now inconsistent? Here's the patch I whipped up at work today (applied to v4.14) that undid enough of this to make the driver work again with platform data on the board we ship: From: Rob Landley The LED driver changes that went in

[PATCH] Fix platform data in leds-pca955x.c

t_trigger pointing to external memory. Is there a reason this is now inconsistent? Here's the patch I whipped up at work today (applied to v4.14) that undid enough of this to make the driver work again with platform data on the board we ship: From: Rob Landley The LED driver changes that went in

Re: [PATCH] kbuild: add machine size to CHEKCFLAGS

On 05/30/2018 05:00 PM, Andreas Färber wrote: > What about the architectures not touched by your patch that previously > had no -m32/-m64? (arc, c6x, h8300, hexagon, m68k, microblaze, nds32, > nios2, openrisc, powerpc, riscv, s390, sh, unicore32, xtensa) > > You forgot to CC them on this patch.

Re: [PATCH] kbuild: add machine size to CHEKCFLAGS

On 05/30/2018 05:00 PM, Andreas Färber wrote: > What about the architectures not touched by your patch that previously > had no -m32/-m64? (arc, c6x, h8300, hexagon, m68k, microblaze, nds32, > nios2, openrisc, powerpc, riscv, s390, sh, unicore32, xtensa) > > You forgot to CC them on this patch.

Re: [PATCH] sh: pass machine size to sparse

On 05/28/2018 11:40 AM, Luc Van Oostenryck wrote: > By default, sparse assumes a 64bit machine when compiled on x86-64 > and 32bit when compiled on anything else. > > This can of course create all sort of problems, like issuing false > warnings like: 'shift too big (32) for type unsigned long',

Re: [PATCH] sh: pass machine size to sparse

On 05/28/2018 11:40 AM, Luc Van Oostenryck wrote: > By default, sparse assumes a 64bit machine when compiled on x86-64 > and 32bit when compiled on anything else. > > This can of course create all sort of problems, like issuing false > warnings like: 'shift too big (32) for type unsigned long',

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

On 05/07/2018 10:55 AM, Rich Felker wrote: > On Mon, May 07, 2018 at 10:28:37AM -0500, Rob Landley wrote: >> >> >> On 05/07/2018 09:45 AM, Rich Felker wrote: >> (You can usually configure/build uboot in a couple different ways, with a >> brain-dead built in

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

On 05/07/2018 10:55 AM, Rich Felker wrote: > On Mon, May 07, 2018 at 10:28:37AM -0500, Rob Landley wrote: >> >> >> On 05/07/2018 09:45 AM, Rich Felker wrote: >> (You can usually configure/build uboot in a couple different ways, with a >> brain-dead built in

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

On 05/07/2018 09:45 AM, Rich Felker wrote: > On Mon, May 07, 2018 at 01:00:17PM +0200, John Paul Adrian Glaubitz wrote: >> On 05/07/2018 03:40 AM, Yoshinori Sato wrote: @Yoshinori: Did the HDL-160U LANDISK device you have use u-boot by default or did you convert it from lilo?

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

On 05/07/2018 09:45 AM, Rich Felker wrote: > On Mon, May 07, 2018 at 01:00:17PM +0200, John Paul Adrian Glaubitz wrote: >> On 05/07/2018 03:40 AM, Yoshinori Sato wrote: @Yoshinori: Did the HDL-160U LANDISK device you have use u-boot by default or did you convert it from lilo?

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

On 05/07/2018 09:43 AM, Rich Felker wrote: > On Mon, May 07, 2018 at 08:40:35AM -0500, Rob Landley wrote: >> On 05/07/2018 06:00 AM, John Paul Adrian Glaubitz wrote: >>> I have been able to boot my own kernel on my USL-5P device, but >>> I could never get it to dete

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

On 05/07/2018 09:43 AM, Rich Felker wrote: > On Mon, May 07, 2018 at 08:40:35AM -0500, Rob Landley wrote: >> On 05/07/2018 06:00 AM, John Paul Adrian Glaubitz wrote: >>> I have been able to boot my own kernel on my USL-5P device, but >>> I could never get it to dete

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

On 05/07/2018 06:00 AM, John Paul Adrian Glaubitz wrote: > I have been able to boot my own kernel on my USL-5P device, but > I could never get it to detect the IDE controller. Do I need > an additional patch for that? On a related note, is there a list of boards anywhere? I'm working on a 7760

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

On 05/07/2018 06:00 AM, John Paul Adrian Glaubitz wrote: > I have been able to boot my own kernel on my USL-5P device, but > I could never get it to detect the IDE controller. Do I need > an additional patch for that? On a related note, is there a list of boards anywhere? I'm working on a 7760

Re: [PATCH] Replace unnecessary perl with sed, printf, and the shell $(( )) operator.

On 04/16/2018 07:09 AM, Russell King - ARM Linux wrote: > On Wed, Apr 11, 2018 at 08:38:37PM -0500, Rob Landley wrote: >> You can build a kernel in a cross compiling environment that doesn't have >> perl >> in the $PATH. Commit 429f7a062e3b broke that for 32 bit arm. Fix it.

Re: [PATCH] Replace unnecessary perl with sed, printf, and the shell $(( )) operator.

On 04/16/2018 07:09 AM, Russell King - ARM Linux wrote: > On Wed, Apr 11, 2018 at 08:38:37PM -0500, Rob Landley wrote: >> You can build a kernel in a cross compiling environment that doesn't have >> perl >> in the $PATH. Commit 429f7a062e3b broke that for 32 bit arm. Fix it.

[PATCH] Replace unnecessary perl with sed, printf, and the shell $(( )) operator.

You can build a kernel in a cross compiling environment that doesn't have perl in the $PATH. Commit 429f7a062e3b broke that for 32 bit arm. Fix it. Signed-off-by: Rob Landley <r...@landley.net> --- arch/arm/boot/compressed/Makefile |9 - 1 file changed, 4 insertions(+), 5 del

[PATCH] Replace unnecessary perl with sed, printf, and the shell $(( )) operator.

You can build a kernel in a cross compiling environment that doesn't have perl in the $PATH. Commit 429f7a062e3b broke that for 32 bit arm. Fix it. Signed-off-by: Rob Landley --- arch/arm/boot/compressed/Makefile |9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

On 03/23/2018 02:06 PM, Matthew Wilcox wrote: > On Fri, Mar 23, 2018 at 02:00:24PM -0400, Rich Felker wrote: >> On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote: >>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote: Current implementation doesn't randomize address

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

On 03/23/2018 02:06 PM, Matthew Wilcox wrote: > On Fri, Mar 23, 2018 at 02:00:24PM -0400, Rich Felker wrote: >> On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote: >>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote: Current implementation doesn't randomize address

Re: [PATCH v3 15/15] selinux: delay sid population for rootfs till init is complete

On 02/20/2018 12:56 PM, Stephen Smalley wrote: > On Fri, 2018-02-16 at 20:33 +, Taras Kondratiuk wrote: >> From: Victor Kamensky >> >> With initramfs cpio format that supports extended attributes >> we need to skip sid population on sys_lsetxattr call from >> initramfs for

Re: [PATCH v3 15/15] selinux: delay sid population for rootfs till init is complete

On 02/20/2018 12:56 PM, Stephen Smalley wrote: > On Fri, 2018-02-16 at 20:33 +, Taras Kondratiuk wrote: >> From: Victor Kamensky >> >> With initramfs cpio format that supports extended attributes >> we need to skip sid population on sys_lsetxattr call from >> initramfs for rootfs if security

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

On 02/16/2018 06:00 PM, h...@zytor.com wrote: > Introducing new, incompatible data formats is an inherently *very* > costly operation; unfortunately many engineers don't seem to have a good grip > of just *how* expensive it is (see "silly embedded nonsense hacks", "too > little, too soon".) So

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

On 02/16/2018 06:00 PM, h...@zytor.com wrote: > Introducing new, incompatible data formats is an inherently *very* > costly operation; unfortunately many engineers don't seem to have a good grip > of just *how* expensive it is (see "silly embedded nonsense hacks", "too > little, too soon".) So

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

On 02/16/2018 02:59 PM, H. Peter Anvin wrote: > On 02/16/18 12:33, 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 initcall and

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

On 02/16/2018 02:59 PM, H. Peter Anvin wrote: > On 02/16/18 12:33, 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 initcall and

tmpfs and brickability (size=50% default considered naieve).

If you have two default tmpfs instances on your box (hi buildroot!) and they're world writeable and a normal user goes "cat /dev/zero > /run/fillit; cat /dev/zero > /tmp/fillit" the system then goes "sh: can't fork" trying to call rm on those files, because they each default to 50% of total system

tmpfs and brickability (size=50% default considered naieve).

If you have two default tmpfs instances on your box (hi buildroot!) and they're world writeable and a normal user goes "cat /dev/zero > /run/fillit; cat /dev/zero > /tmp/fillit" the system then goes "sh: can't fork" trying to call rm on those files, because they each default to 50% of total system

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

On 02/01/2018 04:41 PM, Taras Kondratiuk wrote: > Quoting Mimi Zohar (2018-02-01 13:51:52) >> On Thu, 2018-02-01 at 11:09 -0600, Rob Landley wrote: >>> On 02/01/2018 09:55 AM, Mimi Zohar wrote: >>>> On Thu, 2018-02-01 at 09:20 -0600, Rob Landley wrote: >>>

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

On 02/01/2018 04:41 PM, Taras Kondratiuk wrote: > Quoting Mimi Zohar (2018-02-01 13:51:52) >> On Thu, 2018-02-01 at 11:09 -0600, Rob Landley wrote: >>> On 02/01/2018 09:55 AM, Mimi Zohar wrote: >>>> On Thu, 2018-02-01 at 09:20 -0600, Rob Landley wrote: >>>

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

  1   2   3   4   5   6   7   8   9   10   >