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 n
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
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 by
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 mos
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 are
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):
>>
>
the stack 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/in
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
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 La
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 fi
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.
>
> Cheers
return 200 OK and serve the same content:
> Replace HTTP with HTTPS.
>
> Signed-off-by: Alexander A. Klimov
Acked-by: Rob Landley
Rob
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
>
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 back
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 (https://github
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 up
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 test
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 y
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, wh
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 and
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 fi
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:
https:/
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
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 n
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 encour
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 BIN
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.
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. Libr
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 fi
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
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 receivin
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 WIN
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,
>
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 Uni
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 01:
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 fil
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, perh
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 kerne
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
>&
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 embedded
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
>>
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:
>&
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 pars
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,
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 foreverm
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
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 do
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 goin
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 arch/sh/
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 wil
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 dma_decl
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 as
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.
> How
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-maintaine
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
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.
Confirm
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:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/devinet.c
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
> -
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_of_i
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
ing in the
struct, but the device tree commits added char *default_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 t
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.
A
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', or
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 shell o
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?
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
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
sys
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
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 --
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 retur
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 s
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 you
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
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
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:
>>>
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
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'
&g
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
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
>>
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 =
$ 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 met
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 assert
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
> +++ b/Documentation/early-userspace
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
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
Make
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
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 us
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 implementa
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:
>>
>
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 limi
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
sysc
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 ++
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
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 for Debian bug th
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
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() doesn't
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
>>
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
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&#
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
1 - 100 of 925 matches
Mail list logo
