* Re: mounting squashfs as initrd from RAM
From: Rob Landley @ 2016-04-27 23:46 UTC (permalink / raw)
To: Nick Gifford, linux-embedded@vger.kernel.org
In-Reply-To: <20FFB90893A2AB4492D9DFB3B61CC8C403A3CD25@MBX028-W1-CA-4.exch028.domain.local>
On 04/27/2016 02:03 PM, Nick Gifford wrote:
>
> ________________________________________
> From: Rob Landley [rob@landley.net]
> Sent: Monday, April 25, 2016 7:55 PM
> To: Nick Gifford; linux-embedded@vger.kernel.org
> Subject: Re: mounting squashfs as initrd from RAM
>>> Virtual kernel memory layout:
>>> vector : 0xffff0000 - 0xffff1000 ( 4 kB)
>>> fixmap : 0xffc00000 - 0xffe00000 (2048 kB)
>>> vmalloc : 0xf0000000 - 0xff000000 ( 240 MB)
>
> Because fe7f9000 is off the top of "fixmap", but before the start of
> "vector", so it's in an unmapped area.
>
> [nick] Am I missing something here? Isn't fe7f9000 in the range "vmalloc : 0xf0000000 - 0xff000000"?
You're right, I misread fe7 as ffe7.
It's _really_ hard to read your responses, by the way. The >>> format
exists for a reason, I take it your client can't do replies that way?
>> [nick] Due to reasons above, I my guess is that uboot is moving the
>> image from 0x1000000 to 0x3e7f9000 before booting linux.
>
> Where does it say it's moving it? WHY move it? Why isn't the tftp just
> loading it at the right place to begin with? (The load address is an
> argument to the tftp command.)
>
> And how does 3e7f become f37f? What's the base physical address of your
> fixmap?)
>
> [nick] I don't know why, but uboot is moving it. Snippets from the original log:
> ## Loading init Ramdisk from Legacy Image at 01000000 ...
> Image Type: ARM Linux RAMDisk Image (gzip compressed)
> Data Size: 15958016 Bytes = 15.2 MiB
> Verifying Checksum ... OK
> Loading Ramdisk to 3e7f9000, end 3f731000 ... OK
>
> These tell me that uboot is finding it at 01000000, verifying it, and moving it to 3e7f9000 before booting linux. Then:
Why...?
Is it _just_ moving it, or is it decompressing it? If it decompresses
it, the kernel may not recognize it if it's expected a compressed one.
If it's not decompressing it, how is it "verifying" it?
> DEBUG: phys to virt addr 3e7f9000 --> fe7f9000
>
> tells me that linux has mapped 3e7f9000 (taken from uboot) to virtual address fe7f9000. I don't know why it is not mapped later when trying to access it to copy the rootfs.
Neither do I.
Is this an initrd issue or is this an issue with your board's vmalloc
implementation? Does anything ELSE using vmalloc work?
>>> I added the "DEBUG: phys to virt addr 3e7f9000 --> fe7f9000" where it
>>> looks like 0xfe7f9000 is being mapped for the initrd in
>> arch/arm/mm/init.c.
>>
>> That's a 790 line file, which contains 45 instances of "initrd" but does
>> not contain the word "buf" so i have no idea what variable you printed out.
>>
>> [nick] What I took from this is that after being moved to 0x3e7f9000, it is then being mapped to virtual memory at 0xfe7f9000.
Correction: it's _attempting_ to map it. The fact the result segfaults
when you try to access it is a problem.
> Note that 0xfe7f9000 is the address that is later given to unpack_to_rootfs (with the correct size).
>>
>> And it's architecture independent code where it looks like you're having
>> a board-specific problem. Possibly this is the first vmalloc use in the
>> kernel and vmalloc doesn't work on your board, it's hard to tell from here.
>>
>> [nick] I don't think it is a board problem as everything boots up fine when
>> I mount the rootfs out of flash with kernel arguments of
>> "console=ttyPS1,115200 earlyprintk noinitrd root=/dev/mtdblock6
> rootfstype=squashfs ro"
>
> Your board's memory layout and where your board is telling the kernel to
> look for the initrd data don't line up. That's either a board problem or
> a bootloader config problem.
>
> [nick] I think the path from physical addr 01000000 to physical addr 3e7f9000 to virtual address fe7f9000 shows from the logs. And it seems like fe7f9000 is a valid vmalloc address.
Except for the part where reading from it segfaults.
It's not objecting to the contents of the memory, it's objecting to the
_mapping_. Why is that?
Rob
^ permalink raw reply
* RE: mounting squashfs as initrd from RAM
From: Nick Gifford @ 2016-04-27 19:03 UTC (permalink / raw)
To: Rob Landley, linux-embedded@vger.kernel.org
In-Reply-To: <571ED8BD.2010402@landley.net>
________________________________________
From: Rob Landley [rob@landley.net]
Sent: Monday, April 25, 2016 7:55 PM
To: Nick Gifford; linux-embedded@vger.kernel.org
Subject: Re: mounting squashfs as initrd from RAM
On 04/25/2016 01:36 PM, Nick Gifford wrote:
> Thanks for the help, Rob. Comments inline...
>
> nick
> ________________________________________
> From: Rob Landley [rob@landley.net]
> Sent: Wednesday, April 20, 2016 10:27 AM
> To: Nick Gifford; linux-embedded@vger.kernel.org
> Subject: Re: mounting squashfs as initrd from RAM
>
> On 04/12/2016 04:42 PM, Nick Gifford wrote:
>> I have a squashfs filesystem that I want to mount as initrd. I don't
>> want to use initramfs since the squashfs compresses better. I'm ok
>> with the wasted RAM since our system is much more constrained by flash
>> space than RAM.
>
> Did we ever hook up initramfs xz compression in the kernel? That really
> should compress better than squashfs (for the same reason tar compresses
> better than zip, no need to retain random access capabaility to the data).
>
> [nick] I can look into that. I'm not against using initramfs, but I tried
> that and had a similar issue. My main requirement is that the rootfs
> is not bundled with the kernel.
You can load your initramfs using the old initrd mechanism; if it's a
cpio.gz file the kernel will recognize that and know what to do with it.
(I.E. feed a cpio.gz file in place of your squashfs image, and it should
be extracted to initramfs.)
[nick] I did try a cpio.gz but am having a similar issue with that.
If you have both a static and external initramfs, the static one is
extracted first and then the external one is extracted over it.
(Conflicting files are either replaced or extended depending on your
kernel version.)
>> I want to mount it from RAM so that the flash partition can be safely
>> written/upgraded while linux is running with the RAM copy mounted.
>
> So you're using a squashfs formatted initrd.
> [nick] yes
>
>> Eventually, I want the linux kernel and the initrd to each have their
>> own partition (for upgradeability), but right now I'm just copying them
>> directly into RAM from u-boot and passing the initrd RAM address as the
>> second arg to bootm. Below is my u-boot environment and console log.
>
> Let's see...
>
>> Trying to unpack rootfs image as initramfs...
>> DEBUG unpack_to_rootfs buf=[fe7f9000], len=15958016
>> Unable to handle kernel paging request at virtual address fe7f9000
>
> That second line does not exist in the kernel source I have, so I'm
> guessing that's a debug printf you added. Given that, I don't know if
> that's the source buffer or the destination buffer, but whatever it is
> the kernel can't access it.
>
> [nick] I'll attach a diff below. Those are the arguments to the unpack_to_rootfs function.
Ok, so it looks like your phys_initrd_start isn't mapped.
> Sounds like your u-boot isn't correctly telling the kernel where to find
> the blob it loaded? Let's see...
>
> [nick] I believe uboot is doing the right thing. It was not even booting linux until I got the uboot image header right. Also, the "len=15958016" in my linux debug log is exactly the right size, so the blob size is being passed to linux correctly.
>
>> Virtual kernel memory layout:
>> vector : 0xffff0000 - 0xffff1000 ( 4 kB)
>> fixmap : 0xffc00000 - 0xffe00000 (2048 kB)
>> vmalloc : 0xf0000000 - 0xff000000 ( 240 MB)
Because fe7f9000 is off the top of "fixmap", but before the start of
"vector", so it's in an unmapped area.
[nick] Am I missing something here? Isn't fe7f9000 in the range "vmalloc : 0xf0000000 - 0xff000000"?
Yeah, that'll segfault. What's telling your kernel that this is where to
load the external initrd image from there? (Your bootloader, presumably...)
>> lowmem : 0xc0000000 - 0xef800000 ( 760 MB)
>> pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
>> modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
>> .text : 0xc0008000 - 0xc071b584 (7246 kB)
>> .init : 0xc071c000 - 0xc0756880 ( 235 kB)
>> .data : 0xc0758000 - 0xc07ae0b8 ( 345 kB)
>> .bss : 0xc07ae0b8 - 0xc0fb33b8 (8213 kB)
>
> It's in the vmalloc space. So presumably destination buffer?
>
>> TFTP from server 10.50.4.82; our IP address is 10.50.6.251
>> Filename 'urootfs.squashfs'.
>> Load address: 0x1000000
>
> Your u-boot thinks it loaded the initrd at 0x1000000, which is not
> mentioned in your printk. Not knowing where you added your printk, I
> couldn't tell you what variable it corresponds to...
>
> [nick] Due to reasons above, I my guess is that uboot is moving the
> image from 0x1000000 to 0x3e7f9000 before booting linux.
Where does it say it's moving it? WHY move it? Why isn't the tftp just
loading it at the right place to begin with? (The load address is an
argument to the tftp command.)
And how does 3e7f become f37f? What's the base physical address of your
fixmap?)
[nick] I don't know why, but uboot is moving it. Snippets from the original log:
## Loading init Ramdisk from Legacy Image at 01000000 ...
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 15958016 Bytes = 15.2 MiB
Verifying Checksum ... OK
Loading Ramdisk to 3e7f9000, end 3f731000 ... OK
These tell me that uboot is finding it at 01000000, verifying it, and moving it to 3e7f9000 before booting linux. Then:
DEBUG: phys to virt addr 3e7f9000 --> fe7f9000
tells me that linux has mapped 3e7f9000 (taken from uboot) to virtual address fe7f9000. I don't know why it is not mapped later when trying to access it to copy the rootfs.
> This somewhat makes sense to me since it is near the top of the 1GB
> of RAM on this system.
Is it in the 2 megabyte fixmap window above?
[nick] I think it's in the vmalloc window.
>> Any help on why I'd be seeing the unhandled paging request?
>
> Not without knowing what you've done to your code, no.
>
>> I added the "DEBUG: phys to virt addr 3e7f9000 --> fe7f9000" where it
>> looks like 0xfe7f9000 is being mapped for the initrd in
> arch/arm/mm/init.c.
>
> That's a 790 line file, which contains 45 instances of "initrd" but does
> not contain the word "buf" so i have no idea what variable you printed out.
>
> [nick] What I took from this is that after being moved to 0x3e7f9000, it is then being mapped to virtual memory at 0xfe7f9000. Note that 0xfe7f9000 is the address that is later given to unpack_to_rootfs (with the correct size).
>
> And it's architecture independent code where it looks like you're having
> a board-specific problem. Possibly this is the first vmalloc use in the
> kernel and vmalloc doesn't work on your board, it's hard to tell from here.
>
> [nick] I don't think it is a board problem as everything boots up fine when
> I mount the rootfs out of flash with kernel arguments of
> "console=ttyPS1,115200 earlyprintk noinitrd root=/dev/mtdblock6
rootfstype=squashfs ro"
Your board's memory layout and where your board is telling the kernel to
look for the initrd data don't line up. That's either a board problem or
a bootloader config problem.
[nick] I think the path from physical addr 01000000 to physical addr 3e7f9000 to virtual address fe7f9000 shows from the logs. And it seems like fe7f9000 is a valid vmalloc address.
Rob
^ permalink raw reply
* Re: mounting squashfs as initrd from RAM
From: Rob Landley @ 2016-04-26 2:55 UTC (permalink / raw)
To: Nick Gifford, linux-embedded@vger.kernel.org
In-Reply-To: <20FFB90893A2AB4492D9DFB3B61CC8C403A372F9@MBX028-W1-CA-4.exch028.domain.local>
On 04/25/2016 01:36 PM, Nick Gifford wrote:
> Thanks for the help, Rob. Comments inline...
>
> nick
> ________________________________________
> From: Rob Landley [rob@landley.net]
> Sent: Wednesday, April 20, 2016 10:27 AM
> To: Nick Gifford; linux-embedded@vger.kernel.org
> Subject: Re: mounting squashfs as initrd from RAM
>
> On 04/12/2016 04:42 PM, Nick Gifford wrote:
>> I have a squashfs filesystem that I want to mount as initrd. I don't
>> want to use initramfs since the squashfs compresses better. I'm ok
>> with the wasted RAM since our system is much more constrained by flash
>> space than RAM.
>
> Did we ever hook up initramfs xz compression in the kernel? That really
> should compress better than squashfs (for the same reason tar compresses
> better than zip, no need to retain random access capabaility to the data).
>
> [nick] I can look into that. I'm not against using initramfs, but I tried
> that and had a similar issue. My main requirement is that the rootfs
> is not bundled with the kernel.
You can load your initramfs using the old initrd mechanism; if it's a
cpio.gz file the kernel will recognize that and know what to do with it.
(I.E. feed a cpio.gz file in place of your squashfs image, and it should
be extracted to initramfs.)
If you have both a static and external initramfs, the static one is
extracted first and then the external one is extracted over it.
(Conflicting files are either replaced or extended depending on your
kernel version.)
>> I want to mount it from RAM so that the flash partition can be safely
>> written/upgraded while linux is running with the RAM copy mounted.
>
> So you're using a squashfs formatted initrd.
> [nick] yes
>
>> Eventually, I want the linux kernel and the initrd to each have their
>> own partition (for upgradeability), but right now I'm just copying them
>> directly into RAM from u-boot and passing the initrd RAM address as the
>> second arg to bootm. Below is my u-boot environment and console log.
>
> Let's see...
>
>> Trying to unpack rootfs image as initramfs...
>> DEBUG unpack_to_rootfs buf=[fe7f9000], len=15958016
>> Unable to handle kernel paging request at virtual address fe7f9000
>
> That second line does not exist in the kernel source I have, so I'm
> guessing that's a debug printf you added. Given that, I don't know if
> that's the source buffer or the destination buffer, but whatever it is
> the kernel can't access it.
>
> [nick] I'll attach a diff below. Those are the arguments to the unpack_to_rootfs function.
Ok, so it looks like your phys_initrd_start isn't mapped.
> Sounds like your u-boot isn't correctly telling the kernel where to find
> the blob it loaded? Let's see...
>
> [nick] I believe uboot is doing the right thing. It was not even booting linux until I got the uboot image header right. Also, the "len=15958016" in my linux debug log is exactly the right size, so the blob size is being passed to linux correctly.
>
>> Virtual kernel memory layout:
>> vector : 0xffff0000 - 0xffff1000 ( 4 kB)
>> fixmap : 0xffc00000 - 0xffe00000 (2048 kB)
>> vmalloc : 0xf0000000 - 0xff000000 ( 240 MB)
Because fe7f9000 is off the top of "fixmap", but before the start of
"vector", so it's in an unmapped area.
Yeah, that'll segfault. What's telling your kernel that this is where to
load the external initrd image from there? (Your bootloader, presumably...)
>> lowmem : 0xc0000000 - 0xef800000 ( 760 MB)
>> pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
>> modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
>> .text : 0xc0008000 - 0xc071b584 (7246 kB)
>> .init : 0xc071c000 - 0xc0756880 ( 235 kB)
>> .data : 0xc0758000 - 0xc07ae0b8 ( 345 kB)
>> .bss : 0xc07ae0b8 - 0xc0fb33b8 (8213 kB)
>
> It's in the vmalloc space. So presumably destination buffer?
>
>> TFTP from server 10.50.4.82; our IP address is 10.50.6.251
>> Filename 'urootfs.squashfs'.
>> Load address: 0x1000000
>
> Your u-boot thinks it loaded the initrd at 0x1000000, which is not
> mentioned in your printk. Not knowing where you added your printk, I
> couldn't tell you what variable it corresponds to...
>
> [nick] Due to reasons above, I my guess is that uboot is moving the
> image from 0x1000000 to 0x3e7f9000 before booting linux.
Where does it say it's moving it? WHY move it? Why isn't the tftp just
loading it at the right place to begin with? (The load address is an
argument to the tftp command.)
And how does 3e7f become f37f? What's the base physical address of your
fixmap?)
> This somewhat makes sense to me since it is near the top of the 1GB
> of RAM on this system.
Is it in the 2 megabyte fixmap window above?
>> Any help on why I'd be seeing the unhandled paging request?
>
> Not without knowing what you've done to your code, no.
>
>> I added the "DEBUG: phys to virt addr 3e7f9000 --> fe7f9000" where it
>> looks like 0xfe7f9000 is being mapped for the initrd in
> arch/arm/mm/init.c.
>
> That's a 790 line file, which contains 45 instances of "initrd" but does
> not contain the word "buf" so i have no idea what variable you printed out.
>
> [nick] What I took from this is that after being moved to 0x3e7f9000, it is then being mapped to virtual memory at 0xfe7f9000. Note that 0xfe7f9000 is the address that is later given to unpack_to_rootfs (with the correct size).
>
> And it's architecture independent code where it looks like you're having
> a board-specific problem. Possibly this is the first vmalloc use in the
> kernel and vmalloc doesn't work on your board, it's hard to tell from here.
>
> [nick] I don't think it is a board problem as everything boots up fine when
> I mount the rootfs out of flash with kernel arguments of
> "console=ttyPS1,115200 earlyprintk noinitrd root=/dev/mtdblock6
rootfstype=squashfs ro"
Your board's memory layout and where your board is telling the kernel to
look for the initrd data don't line up. That's either a board problem or
a bootloader config problem.
Rob
^ permalink raw reply
* RE: mounting squashfs as initrd from RAM
From: Nick Gifford @ 2016-04-25 18:36 UTC (permalink / raw)
To: Rob Landley, linux-embedded@vger.kernel.org
In-Reply-To: <5717BBF5.1000401@landley.net>
Thanks for the help, Rob. Comments inline...
nick
________________________________________
From: Rob Landley [rob@landley.net]
Sent: Wednesday, April 20, 2016 10:27 AM
To: Nick Gifford; linux-embedded@vger.kernel.org
Subject: Re: mounting squashfs as initrd from RAM
On 04/12/2016 04:42 PM, Nick Gifford wrote:
> I have a squashfs filesystem that I want to mount as initrd. I don't
> want to use initramfs since the squashfs compresses better. I'm ok
> with the wasted RAM since our system is much more constrained by flash
> space than RAM.
Did we ever hook up initramfs xz compression in the kernel? That really
should compress better than squashfs (for the same reason tar compresses
better than zip, no need to retain random access capabaility to the data).
[nick] I can look into that. I'm not against using initramfs, but I tried that and had a similar issue. My main requirement is that the rootfs is not bundled with the kernel.
> I want to mount it from RAM so that the flash partition can be safely
> written/upgraded while linux is running with the RAM copy mounted.
So you're using a squashfs formatted initrd.
[nick] yes
> Eventually, I want the linux kernel and the initrd to each have their
> own partition (for upgradeability), but right now I'm just copying them
> directly into RAM from u-boot and passing the initrd RAM address as the
> second arg to bootm. Below is my u-boot environment and console log.
Let's see...
> Trying to unpack rootfs image as initramfs...
> DEBUG unpack_to_rootfs buf=[fe7f9000], len=15958016
> Unable to handle kernel paging request at virtual address fe7f9000
That second line does not exist in the kernel source I have, so I'm
guessing that's a debug printf you added. Given that, I don't know if
that's the source buffer or the destination buffer, but whatever it is
the kernel can't access it.
[nick] I'll attach a diff below. Those are the arguments to the unpack_to_rootfs function.
Sounds like your u-boot isn't correctly telling the kernel where to find
the blob it loaded? Let's see...
[nick] I believe uboot is doing the right thing. It was not even booting linux until I got the uboot image header right. Also, the "len=15958016" in my linux debug log is exactly the right size, so the blob size is being passed to linux correctly.
> Virtual kernel memory layout:
> vector : 0xffff0000 - 0xffff1000 ( 4 kB)
> fixmap : 0xffc00000 - 0xffe00000 (2048 kB)
> vmalloc : 0xf0000000 - 0xff000000 ( 240 MB)
> lowmem : 0xc0000000 - 0xef800000 ( 760 MB)
> pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
> modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
> .text : 0xc0008000 - 0xc071b584 (7246 kB)
> .init : 0xc071c000 - 0xc0756880 ( 235 kB)
> .data : 0xc0758000 - 0xc07ae0b8 ( 345 kB)
> .bss : 0xc07ae0b8 - 0xc0fb33b8 (8213 kB)
It's in the vmalloc space. So presumably destination buffer?
> TFTP from server 10.50.4.82; our IP address is 10.50.6.251
> Filename 'urootfs.squashfs'.
> Load address: 0x1000000
Your u-boot thinks it loaded the initrd at 0x1000000, which is not
mentioned in your printk. Not knowing where you added your printk, I
couldn't tell you what variable it corresponds to...
[nick] Due to reasons above, I my guess is that uboot is moving the image from 0x1000000 to 0x3e7f9000 before booting linux. This somewhat makes sense to me since it is near the top of the 1GB of RAM on this system.
> Any help on why I'd be seeing the unhandled paging request?
Not without knowing what you've done to your code, no.
> I added the "DEBUG: phys to virt addr 3e7f9000 --> fe7f9000" where it
> looks like 0xfe7f9000 is being mapped for the initrd in
arch/arm/mm/init.c.
That's a 790 line file, which contains 45 instances of "initrd" but does
not contain the word "buf" so i have no idea what variable you printed out.
[nick] What I took from this is that after being moved to 0x3e7f9000, it is then being mapped to virtual memory at 0xfe7f9000. Note that 0xfe7f9000 is the address that is later given to unpack_to_rootfs (with the correct size).
And it's architecture independent code where it looks like you're having
a board-specific problem. Possibly this is the first vmalloc use in the
kernel and vmalloc doesn't work on your board, it's hard to tell from here.
[nick] I don't think it is a board problem as everything boots up fine when I mount the rootfs out of flash with kernel arguments of "console=ttyPS1,115200 earlyprintk noinitrd root=/dev/mtdblock6 rootfstype=squashfs ro"
Rob
[nick] And here is the diff:
[ngifford@localhost xlnx-3.17]$ svn diff
Index: init/initramfs.c
===================================================================
--- init/initramfs.c (revision 103446)
+++ init/initramfs.c (working copy)
@@ -463,6 +463,7 @@
state = Start;
this_header = 0;
message = NULL;
+ printk(KERN_INFO "DEBUG unpack_to_rootfs buf=[%x], len=%d\n", buf, len);
while (!message && len) {
loff_t saved_offset = this_header;
if (*buf == '0' && !(this_header & 3)) {
@@ -616,6 +617,7 @@
printk(KERN_INFO "Trying to unpack rootfs image as initramfs...\n");
err = unpack_to_rootfs((char *)initrd_start,
initrd_end - initrd_start);
+
if (!err) {
free_initrd();
goto done;
Index: arch/arm/mm/init.c
===================================================================
--- arch/arm/mm/init.c (revision 103446)
+++ arch/arm/mm/init.c (working copy)
@@ -60,6 +60,7 @@
phys_initrd_start = start;
phys_initrd_size = size;
+ printk(KERN_WARNING "early_initrd %x %d", phys_initrd_start, phys_initrd_size);
}
return 0;
}
@@ -80,6 +81,7 @@
{
phys_initrd_start = tag->u.initrd.start;
phys_initrd_size = tag->u.initrd.size;
+ printk(KERN_WARNING "parse_tag_initrd2 %x %d", phys_initrd_start, phys_initrd_size);
return 0;
}
@@ -306,6 +308,7 @@
/* Now convert initrd to virtual addresses */
initrd_start = __phys_to_virt(phys_initrd_start);
+ printk(KERN_INFO "DEBUG: phys to virt addr %x --> %x", phys_initrd_start, initrd_start);
initrd_end = initrd_start + phys_initrd_size;
}
#endif
^ permalink raw reply
* Re: mounting squashfs as initrd from RAM
From: Rob Landley @ 2016-04-20 17:27 UTC (permalink / raw)
To: Nick Gifford, linux-embedded@vger.kernel.org
In-Reply-To: <20FFB90893A2AB4492D9DFB3B61CC8C403A15778@MBX028-W1-CA-4.exch028.domain.local>
On 04/12/2016 04:42 PM, Nick Gifford wrote:
> I have a squashfs filesystem that I want to mount as initrd. I don't
> want to use initramfs since the squashfs compresses better. I'm ok
> with the wasted RAM since our system is much more constrained by flash
> space than RAM.
Did we ever hook up initramfs xz compression in the kernel? That really
should compress better than squashfs (for the same reason tar compresses
better than zip, no need to retain random access capabaility to the data).
> I want to mount it from RAM so that the flash partition can be safely
> written/upgraded while linux is running with the RAM copy mounted.
So you're using a squashfs formatted initrd.
> Eventually, I want the linux kernel and the initrd to each have their
> own partition (for upgradeability), but right now I'm just copying them
> directly into RAM from u-boot and passing the initrd RAM address as the
> second arg to bootm. Below is my u-boot environment and console log.
Let's see...
> Trying to unpack rootfs image as initramfs...
> DEBUG unpack_to_rootfs buf=[fe7f9000], len=15958016
> Unable to handle kernel paging request at virtual address fe7f9000
That second line does not exist in the kernel source I have, so I'm
guessing that's a debug printf you added. Given that, I don't know if
that's the source buffer or the destination buffer, but whatever it is
the kernel can't access it.
Sounds like your u-boot isn't correctly telling the kernel where to find
the blob it loaded? Let's see...
> Virtual kernel memory layout:
> vector : 0xffff0000 - 0xffff1000 ( 4 kB)
> fixmap : 0xffc00000 - 0xffe00000 (2048 kB)
> vmalloc : 0xf0000000 - 0xff000000 ( 240 MB)
> lowmem : 0xc0000000 - 0xef800000 ( 760 MB)
> pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
> modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
> .text : 0xc0008000 - 0xc071b584 (7246 kB)
> .init : 0xc071c000 - 0xc0756880 ( 235 kB)
> .data : 0xc0758000 - 0xc07ae0b8 ( 345 kB)
> .bss : 0xc07ae0b8 - 0xc0fb33b8 (8213 kB)
It's in the vmalloc space. So presumably destination buffer?
> TFTP from server 10.50.4.82; our IP address is 10.50.6.251
> Filename 'urootfs.squashfs'.
> Load address: 0x1000000
Your u-boot thinks it loaded the initrd at 0x1000000, which is not
mentioned in your printk. Not knowing where you added your printk, I
couldn't tell you what variable it corresponds to...
> Any help on why I'd be seeing the unhandled paging request?
Not without knowing what you've done to your code, no.
> I added the "DEBUG: phys to virt addr 3e7f9000 --> fe7f9000" where it
> looks like 0xfe7f9000 is being mapped for the initrd in
arch/arm/mm/init.c.
That's a 790 line file, which contains 45 instances of "initrd" but does
not contain the word "buf" so i have no idea what variable you printed out.
And it's architecture independent code where it looks like you're having
a board-specific problem. Possibly this is the first vmalloc use in the
kernel and vmalloc doesn't work on your board, it's hard to tell from here.
Rob
^ permalink raw reply
* mounting squashfs as initrd from RAM
From: Nick Gifford @ 2016-04-12 21:42 UTC (permalink / raw)
To: linux-embedded@vger.kernel.org
I have a squashfs filesystem that I want to mount as initrd. I don't want to use initramfs since the squashfs compresses better. I'm ok with the wasted RAM since our system is much more constrained by flash space than RAM.
I want to mount it from RAM so that the flash partition can be safely written/upgraded while linux is running with the RAM copy mounted.
Eventually, I want the linux kernel and the initrd to each have their own partition (for upgradeability), but right now I'm just copying them directly into RAM from u-boot and passing the initrd RAM address as the second arg to bootm. Below is my u-boot environment and console log.
Any help on why I'd be seeing the unhandled paging request? I added the "DEBUG: phys to virt addr 3e7f9000 --> fe7f9000" where it looks like 0xfe7f9000 is being mapped for the initrd in arch/arm/mm/init.c.
nick
U-Boot 2014.07 (Apr 08 2016 - 09:31:37)
I2C: ready
DRAM: ECC disabled 1020 MiB
MMC: zynq_sdhci: 0
SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256 KiB, total 128 MiB
In: serial
Out: serial
Err: serial
ENET MAC Address found in EEPROM - env setting for macaddr overridden
Net: Gem.e000b000
Hit any key to stop autoboot: 0
U-Boot-PetaLinux> printenv
autoload=no
baudrate=115200
boot_img=BOOT.BIN
bootcmd=run default_bootcmd
bootdelay=4
bootenvsize=0x40000
bootenvstart=0x700000
bootsize=0x700000
bootstart=0x0
clobstart=0x08000000
console=console=ttyPS0,115200
cp_kernel2ram=sf probe 0 && sf read ${netstart} ${kernelstart} ${kernelsize}
default_bootcmd=run cp_kernel2ram && bootm ${netstart}
dtbnetstart=0x09800000
eraseenv=sf probe 0 && sf erase ${bootenvstart} ${bootenvsize}
ethact=Gem.e000b000
ethaddr=00:25:0f:03:06:8a
fault=echo ${img} image size is greater than allocated place - partition ${img} is NOT UPDATED
fileaddr=8000000
filesize=3c4444
gatewayip=10.50.4.1
hostname=pliny
initrd_high=0x0
install_boot=sf probe 0 && sf erase ${bootstart} ${bootsize} && sf write ${clobstart} ${bootstart} ${filesize}
install_jffs2=sf probe 0 && sf erase ${jffs2start} ${jffs2size} && sf write ${clobstart} ${jffs2start} ${filesize}
install_kernel=sf probe 0 && sf erase ${kernelstart} ${kernelsize} && sf write ${clobstart} ${kernelstart} ${filesize}
install_orwsquashfs=sf probe 0 && sf erase ${orwsquashfsstart} ${orwsquashfssize} && sf write ${clobstart} ${orwsquashfsstart} ${filesize}
install_squashfs=sf probe 0 && sf erase ${squashfsstart} ${squashfssize} && sf write ${clobstart} ${squashfsstart} ${filesize}
ipaddr=10.50.6.251
jffs2_img=rootfs.jffs2
kernel_img=image.ub
kernelsize=0x800000
kernelstart=0x800000
load_boot=tftp ${clobstart} ${boot_img}
load_jffs2=tftp ${clobstart} ${jffs2_img}
load_kernel=tftp ${clobstart} ${kernel_img}
load_orwsquashfs=tftp ${clobstart} ${orwsquashfs_img}
load_squashfs=tftp ${clobstart} ${squashfs_img}
loadaddr=0x08000000
nc=setenv stdout nc;setenv stdin nc;
netboot=tftp ${netstart} ${kernel_img} && bootm
netmask=255.255.252.0
netstart=0x08000000
orw_data_size=0x2000000
orw_data_start=0x6000000
orw_full_reset=run orw_updateall && run orw_nuke_data
orw_logs_size=0xe00000
orw_logs_start=0x3200000
orw_nuke_data=sf probe 0 && sf erase ${orw_reserved_start} ${orw_reserved_size} && sf erase ${orw_rootfs_data_start} ${orw_rootfs_data_size} && sf erase ${orw_logs_start} ${orw_logs_size} && sf erase ${orw_data_start} ${orw_d}
orw_reserved_size=0xc0000
orw_reserved_start=0x740000
orw_rootfs_data_size=0x200000
orw_rootfs_data_start=0x3000000
orw_sd_full_reset=run orw_sd_updateall && run orw_nuke_data
orw_sd_updateall=run sd_update_boot && run sd_update_squashfs && run sd_update_kernel && run sd_update_orwsquashfs
orw_updateall=run update_boot && run update_squashfs && run update_kernel && run update_orwsquashfs
orwsquashfs_img=orw.squashfs
orwsquashfssize=0x2000000
orwsquashfsstart=0x4000000
psserial0=setenv stdout ttyPS0;setenv stdin ttyPS0
sd_update_boot=echo Updating boot from SD; mmcinfo && fatload mmc 0:1 ${clobstart} ${boot_img} && run install_boot
sd_update_jffs2=echo Updating jffs2 from SD; mmcinfo && fatload mmc 0:1 ${clobstart} ${jffs2_img} && run install_jffs2
sd_update_kernel=echo Updating kernel from SD; mmcinfo && fatload mmc 0:1 ${clobstart} ${kernel_img} && run install_kernel
sd_update_orwsquashfs=echo Updating orwsquashfs from SD; mmcinfo && fatload mmc 0:1 ${clobstart} ${orwsquashfs_img} && run install_orwsquashfs
sd_update_squashfs=echo Updating squashfs from SD; mmcinfo && fatload mmc 0:1 ${clobstart} ${squashfs_img} && run install_squashfs
sdboot=echo boot Petalinux; mmcinfo && fatload mmc 0 ${netstart} ${kernel_img} && bootm
serial=setenv stdout serial;setenv stdin serial
serverip=10.50.4.82
squashfs_img=urootfs.squashfs
squashfssize=0x2000000
squashfsstart=0x1000000
test_boot=tftp 0x08000000 image.ub && tftp 0x01000000 urootfs.squashfs && bootm 0x08000000 0x01000000
test_crc=if imi ${clobstart}; then run test_img; else echo ${img} Bad CRC - ${img} is NOT UPDATED; fi
test_img=setenv var "if test ${filesize} -gt ${psize}; then run fault; else run ${installcmd}; fi"; run var; setenv var
update_boot=setenv img boot; setenv psize ${bootsize}; setenv installcmd "install_boot"; run load_boot test_img; setenv img; setenv psize; setenv installcmd
update_jffs2=setenv img jffs2; setenv psize ${jffs2size}; setenv installcmd "install_jffs2"; run load_jffs2 test_img; setenv img; setenv psize; setenv installcmd
update_kernel=setenv img kernel; setenv psize ${kernelsize}; setenv installcmd "install_kernel"; run load_kernel test_crc; setenv img; setenv psize; setenv installcmd
update_orwsquashfs=setenv img orwsquashfs; setenv psize ${orwsquashfssize}; setenv installcmd "install_orwsquashfs"; run load_orwsquashfs test_img; setenv img; setenv psize; setenv installcmd
update_squashfs=setenv img squashfs; setenv psize ${squashfssize}; setenv installcmd "install_squashfs"; run load_squashfs test_img; setenv img; setenv psize; setenv installcmd
Environment size: 4856/262140 bytes
U-Boot-PetaLinux> run test_boot
Gem.e000b000 Waiting for PHY auto negotiation to complete.... done
Using Gem.e000b000 device
TFTP from server 10.50.4.82; our IP address is 10.50.6.251
Filename 'image.ub'.
Load address: 0x8000000
Loading: T #################################################################
#################################################################
#################################################################
#################################################################
##########
672.9 KiB/s
done
Bytes transferred = 3949444 (3c4384 hex)
Gem.e000b000:1 is connected to Gem.e000b000. Reconnecting to Gem.e000b000
Gem.e000b000 Waiting for PHY auto negotiation to complete... done
Using Gem.e000b000 device
TFTP from server 10.50.4.82; our IP address is 10.50.6.251
Filename 'urootfs.squashfs'.
Load address: 0x1000000
Loading: T #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
################################################
1.9 MiB/s
done
Bytes transferred = 15958080 (f38040 hex)
## Loading kernel from FIT Image at 08000000 ...
Using 'conf@1' configuration
Trying 'kernel@1' kernel subimage
Description: PetaLinux Kernel
Type: Kernel Image
Compression: gzip compressed
Data Start: 0x080000f0
Data Size: 3930908 Bytes = 3.7 MiB
Architecture: ARM
OS: Linux
Load Address: 0x00008000
Entry Point: 0x00008000
Hash algo: crc32
Hash value: 5ac4c408
Verifying Hash Integrity ... crc32+ OK
## Loading init Ramdisk from Legacy Image at 01000000 ...
Image Name:
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 15958016 Bytes = 15.2 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Loading fdt from FIT Image at 08000000 ...
Using 'conf@1' configuration
Trying 'fdt@1' fdt subimage
Description: Flattened Device Tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x083bfcf0
Data Size: 17240 Bytes = 16.8 KiB
Architecture: ARM
Hash algo: crc32
Hash value: 348735df
Verifying Hash Integrity ... crc32+ OK
Booting using the fdt blob at 0x83bfcf0
Uncompressing Kernel Image ... OK
Loading Ramdisk to 3e7f9000, end 3f731000 ... OK
Loading Device Tree to 07ff8000, end 07fff357 ... OK
Starting kernel ...
Booting Linux on physical CPU 0x0
Linux version 3.17.0-xilinx-svn96060 (ngifford@localhost.localdomain) (gcc version 4.8.3 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-23) ) #29 SMP PREEMPT Tue Apr 12 14:20:58 PDT 2016
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine model: pliny
bootconsole [earlycon0] enabled
DEBUG: phys to virt addr 3e7f9000 --> fe7f9000
Memory policy: Data cache writealloc
PERCPU: Embedded 8 pages/cpu @eefd2000 s10368 r8192 d14208 u32768
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 259600
Kernel command line: console=ttyPS1,115200 earlyprintk root=/dev/ram0 rootfstype=squashfs rw
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1003644K/1044480K available (5328K kernel code, 344K rwdata, 1916K rodata, 234K init, 8212K bss, 40836K reserved, 250656K highmem)
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xffc00000 - 0xffe00000 (2048 kB)
vmalloc : 0xf0000000 - 0xff000000 ( 240 MB)
lowmem : 0xc0000000 - 0xef800000 ( 760 MB)
pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
.text : 0xc0008000 - 0xc071b584 (7246 kB)
.init : 0xc071c000 - 0xc0756880 ( 235 kB)
.data : 0xc0758000 - 0xc07ae0b8 ( 345 kB)
.bss : 0xc07ae0b8 - 0xc0fb33b8 (8213 kB)
Preemptible hierarchical RCU implementation.
RCU lockdep checking is enabled.
Dump stacks of tasks blocking RCU-preempt GP.
RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
NR_IRQS:16 nr_irqs:16 16
L2C: platform provided aux values match the hardware, so have no effect. Please remove them.
L2C-310 erratum 769419 enabled
L2C-310 enabling early BRESP for Cortex-A9
L2C-310 full line of zeros enabled for Cortex-A9
L2C-310 ID prefetch enabled, offset 1 lines
L2C-310 dynamic clock gating enabled, standby mode enabled
L2C-310 cache controller enabled, 8 ways, 512 kB
L2C-310: CACHE_ID 0x410000c8, AUX_CTRL 0x76360001
slcr mapped to f0006000
zynq_clock_init: clkc starts at f0006100
Zynq clock init
sched_clock: 64 bits at 333MHz, resolution 3ns, wraps every 3298534883328ns
timer #0 at f0008000, irq=43
Console: colour dummy device 80x30
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES: 8
... MAX_LOCK_DEPTH: 48
... MAX_LOCKDEP_KEYS: 8191
... CLASSHASH_SIZE: 4096
... MAX_LOCKDEP_ENTRIES: 32768
... MAX_LOCKDEP_CHAINS: 65536
... CHAINHASH_SIZE: 32768
memory used by lock dependency info: 5167 kB
per task-struct memory footprint: 1152 bytes
Calibrating delay loop... 1325.46 BogoMIPS (lpj=6627328)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0x50eaf0 - 0x50eb48
CPU1: Booted secondary processor
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
Brought up 2 CPUs
SMP: Total of 2 processors activated.
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
cpuidle: using governor ladder
cpuidle: using governor menu
hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
hw-breakpoint: maximum watchpoint size is 4 bytes.
zynq-ocm f800c000.ocmc: ZYNQ OCM pool: 256 KiB @ 0xf0080000
VCCPINT: 1000 mV
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
PTP clock support registered
EDAC MC: Ver: 3.0.0
DMA-API: preallocated 4096 debug entries
DMA-API: debugging enabled by kernel config
Switched to clocksource arm_global_timer
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 8192 (order: 6, 294912 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 3, 40960 bytes)
UDP-Lite hash table entries: 512 (order: 3, 40960 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
DEBUG unpack_to_rootfs buf=[c0753a38], len=133
Trying to unpack rootfs image as initramfs...
DEBUG unpack_to_rootfs buf=[fe7f9000], len=15958016
Unable to handle kernel paging request at virtual address fe7f9000
pgd = c0004000
[fe7f9000] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.17.0-xilinx-svn96060 #29
task: ee857440 ti: ee858000 task.ti: ee858000
PC is at unpack_to_rootfs+0xb4/0x2c0
LR is at unpack_to_rootfs+0xa0/0x2c0
pc : [<c071e3ac>] lr : [<c071e398>] psr: 20000113
sp : ee859e40 ip : 00000001 fp : 00000000
r10: 00000000 r9 : c07ae10c r8 : c07ae110
r7 : c074ad68 r6 : fe7f9000 r5 : 00f38000 r4 : c074ad68
r3 : ee857440 r2 : 00000000 r1 : 00000000 r0 : 00000033
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 18c5387d Table: 0000404a DAC: 00000015
Process swapper/0 (pid: 1, stack limit = 0xee858240)
Stack: (0xee859e40 to 0xee85a000)
9e40: 00000000 c0763ce0 c07ae0c0 c07ae110 c07ae10c ee858038 00000000 c0506cb0
9e60: c0630f16 c07ae110 00000000 c0763ce0 c07ae0c0 c07ae110 c07ae10c ee858038
9e80: 00000000 c071eb94 c071eb38 c0059cb0 ff0a0005 ffffffff 000000d0 ee859ef0
9ea0: c063e56e 00000010 eea69480 c071eb38 ee857440 ee858008 00000001 c00d8268
9ec0: c071eb38 c0059cb0 ee88ac00 eea69480 a0000113 eea69480 c0763ce0 c0763ce0
9ee0: c07ae0c0 c071eb38 000000b0 ee858038 00000000 c0008990 00000001 00000080
9f00: ee8578c8 00000000 ee857400 00000006 00000007 c06ee208 00000000 ef7fcdc5
9f20: 00000000 c003f144 00000001 c050e01c c07ae0c0 c06ee208 c06ed708 000000b0
9f40: 00000005 00000005 c076bd24 00000005 c074acd8 c07536c8 c07ae0c0 c07ae0c0
9f60: 000000b0 c074ace8 00000000 c071ccec 00000005 00000005 c071c51c efff77ff
9f80: ff3f2fbe eefd4080 00000000 c0503d48 00000000 00000000 00000000 00000000
9fa0: 00000000 c0503d50 00000000 c000e868 00000000 00000000 00000000 00000000
9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 dfd77fbf fcfb8faf
[<c071e3ac>] (unpack_to_rootfs) from [<c071eb94>] (populate_rootfs+0x5c/0x248)
[<c071eb94>] (populate_rootfs) from [<c0008990>] (do_one_initcall+0x110/0x1c0)
[<c0008990>] (do_one_initcall) from [<c071ccec>] (kernel_init_freeable+0x10c/0x1d0)
[<c071ccec>] (kernel_init_freeable) from [<c0503d50>] (kernel_init+0x8/0xe4)
[<c0503d50>] (kernel_init) from [<c000e868>] (ret_from_fork+0x14/0x2c)
Code: e3510000 1a000055 e3550000 0a000053 (e5d63000)
---[ end trace 7ff8bbcb926fd04d ]---
Kernel panic - not syncing: Fatal exception
CPU0: stopping
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G D 3.17.0-xilinx-svn96060 #29
[<c0015c54>] (unwind_backtrace) from [<c0011c2c>] (show_stack+0x10/0x14)
[<c0011c2c>] (show_stack) from [<c0508118>] (dump_stack+0x90/0xd4)
[<c0508118>] (dump_stack) from [<c00140a4>] (ipi_cpu_stop+0x3c/0x70)
[<c00140a4>] (ipi_cpu_stop) from [<c00146d4>] (handle_IPI+0x68/0xac)
[<c00146d4>] (handle_IPI) from [<c00085cc>] (gic_handle_irq+0x58/0x60)
[<c00085cc>] (gic_handle_irq) from [<c00126c4>] (__irq_svc+0x44/0x7c)
Exception stack(0xc0759f60 to 0xc0759fa8)
9f60: c000f3e0 00000000 00000000 00000000 00000000 c0758000 c0755288 00000000
9f80: ffffffed c0511294 c0758000 00000000 00000000 c0759fa8 c000f3e0 c000f3e4
9fa0: 60000013 ffffffff
[<c00126c4>] (__irq_svc) from [<c000f3e4>] (arch_cpu_idle+0x30/0x3c)
[<c000f3e4>] (arch_cpu_idle) from [<c00559b0>] (cpu_startup_entry+0xe4/0x210)
[<c00559b0>] (cpu_startup_entry) from [<c071cb78>] (start_kernel+0x34c/0x3b4)
[<c071cb78>] (start_kernel) from [<00008074>] (0x8074)
---[ end Kernel panic - not syncing: Fatal exception
U-Boot 2014.07 (Apr 08 2016 - 09:31:37)
I2C: ready
DRAM: ECC disabled 1020 MiB
MMC: zynq_sdhci: 0
SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256 KiB, total 128 MiB
In: serial
Out: serial
Err: serial
ENET MAC Address found in EEPROM - env setting for macaddr overridden
Net: Gem.e000b000
Hit any key to stop autoboot: 0
U-Boot-PetaLinux>
^ permalink raw reply
* CFP: Embedded, mobile and automotive devroom FOSDEM 2016
From: Geert Uytterhoeven @ 2015-11-23 7:54 UTC (permalink / raw)
To: Linux Embedded
Call For Participation
Embedded, mobile and automotive devroom FOSDEM 2016
Devroom date: Saturday January 30st and Sunday 31st 2016 in Brussels,
Belgium
CFP deadline: Monday, December 7th 2015
Final speaker confirmation on Friday, December 18th 2015
CFP Introduction
---------------------------
Embedded software is transforming the world, and FOSS embedded software
is leading the way. From automotive to the Internet of Things,
launching rockets, messing with your phone or automating your toaster,
small devices, embedded systems, and automatons are everywhere
Join in and tell the world about your project!
NB: This year FOSDEM plans to record all presentations, no exceptions.
Please only propose a talk that you're really able and willing to share.
Topics Sought
------------------------
The embedded devroom seeks topics related to automotive, mobile,
autonomous, and generally small systems. Related areas are of course of
interest as
well and our definition of "embedded" is elastic.
CFP Schedule And Submission Details
-----------------------------------------------------------
Please submit proposals no later than the 7th of December.
Please use the following URL to submit your talk to FOSDEM 2016:
https://penta.fosdem.org/submission/FOSDEM16
and follow the following rules:
* If you do not have an account yet create one, if you have submitted
a talk in one of the previous years re-use your old account.
* Select as the Track "embedded devroom".
* Select as the Event Type "Lecture"
* Include a title. (Note that "Subtitle" entry doesn't appear on
all conference documents, so make sure "Title" can stand on its
own without "Subtitle" present.)
* Include an Abstract of about 500 characters and a full description
of any length you wish, but in both fields, please be concise, but
clear and descriptive.
* Indicate whether you seek a 25, or 50 minute slot.
* Use the "Links" sub-area to your past work in the field you'd like
to share.
* Also in the notes field, confirmation your availability to speak on
Saturday 30 January or 31 February 2016 in Brussels.
* Last but not least, make sure you have up to date contact info.
Feel free to send an email to the embedded mailing list should you have
any questions with the conference system.
Subscribe here: https://lists.fosdem.org/listinfo/embedded-devroom
About the devroom organizers
--------------------------------------------------
The co-organizers of the FOSDEM 2016 Embedded devroom are
(in alphabetical order by surname):
- Peter De Schrijver, Kernel engineer at Nvidia
- Philippe De Swert, HW adaptation engineer at Jolla
- Jeremiah C. Foster, GENIVI Community Manager
- Thomas Petazzoni, CTO Free Electrons
- Geert Uytterhoeven, Glider bvba
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Can the Nexus 5's ARM-SMMU isolate the baseband processor?
From: Richard Yao @ 2015-11-22 0:57 UTC (permalink / raw)
To: linux-embedded
[-- Attachment #1: Type: text/plain, Size: 715 bytes --]
Can the Nexus 5's ARM-SMMU isolate the baseband processor and if it can,
does anything need to be done to enable it to actually do that on Linux?
Myself and a couple others are thinking of trying to port Gentoo Linux
to phone hardware. The Nexus 5 seems to be a decent candidate because
its hardware is relatively recent with nice specifications, it is on
sale for $199.99 and it appears to have open source drivers available
for most of its components (although not all are mainline currently).
I need to know the answer to the subject question before I pull the
trigger on this (as the money for this would be coming out of my
pocket). If the answer is no, then I will need to find another phone.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: MFD device driver on top of UART/RS232
From: H. Nikolaus Schaller @ 2015-11-17 14:16 UTC (permalink / raw)
To: Andrey Vostrikov
Cc: Sascha Hauer, linux-serial, linux-embedded, NeilBrown,
Marek Belisko
In-Reply-To: <564B2166.2030209@gmail.com>
Hi Andrey,
Am 17.11.2015 um 13:45 schrieb Andrey Vostrikov <av.linux.dev@gmail.com>:
> Hi Sascha,
>
> Sascha Hauer wrote:
>> Hi Andrey,
>>
>> +Cc NeilBrown <neil@brown.name>
>>
>> On Mon, Nov 16, 2015 at 07:24:58PM +0300, Andrey Vostrikov wrote:
>>> Hi,
>>>
>>> I have an embedded system with microcontroller connected via
>>> UART/RS232 port. This microcontroller implements several low-level
>>> functions that need to be exposed as device drivers in other
>>> subsystems (watchdog, LEDs, HWMON, firmware read/write).
>>>
>>> I checked many drivers implemented in the kernel, searched through
>>> mail list archives and it looks like there are three different ways to
>>> solve this task:
>>> A) most of the devices that are connected using UART have user space
>>> program that configures and manages it (either directly or with help
>>> of dedicated line discipline, SLIP, SL-CAN, etc)
>>> B) serio - mostly used for input devices
>>> C) direct use of UART port taking control from serial_core.
>>>
>>> The best match I have found so far is MFD driver for Atmel
>>> Microcontroller on iPaq h3xxx (drivers/mfd/ipaq-micro.c) that follows
>>> concept "C)"
>>
>> There's also D) TTY slave device support: https://lkml.org/lkml/2015/3/18/40
>>
>> Unfortunately this hasn't made it to mainline yet and it seems the
>> parties lost interest after some lengthy discussion of device tree phandles
>> vs. subnodes, but I think this is what you're looking for.
>
> Thank you for pointing out to another option. Looks like it was developed a little further and was submitted as patch by "H. Nikolaus Schaller",
> https://lkml.org/lkml/2015/10/16/729
>
> But I see no further traces of it.
Well, I was still missing a technical discussion of our proposals and a real
evaluation of the benefits of subnode vs. phandle. In my view it was very
ideologic and it was not an exchange of arguments.
> Cc'ed Nikolaus, may be he could comment on state of UART slave patch.
And we are currently working on a compromise. So that the DT developer can
simply choose if he prefers subnode or phandle. And the driver is capable of
handling both. This is not yet finished, so we have not yet submitted an update.
BR,
Nikolaus
^ permalink raw reply
* Re: MFD device driver on top of UART/RS232
From: Andrey Vostrikov @ 2015-11-17 12:45 UTC (permalink / raw)
To: Sascha Hauer; +Cc: linux-serial, linux-embedded, NeilBrown, hns
In-Reply-To: <20151117075330.GJ8526@pengutronix.de>
Hi Sascha,
Sascha Hauer wrote:
> Hi Andrey,
>
> +Cc NeilBrown <neil@brown.name>
>
> On Mon, Nov 16, 2015 at 07:24:58PM +0300, Andrey Vostrikov wrote:
>> Hi,
>>
>> I have an embedded system with microcontroller connected via
>> UART/RS232 port. This microcontroller implements several low-level
>> functions that need to be exposed as device drivers in other
>> subsystems (watchdog, LEDs, HWMON, firmware read/write).
>>
>> I checked many drivers implemented in the kernel, searched through
>> mail list archives and it looks like there are three different ways to
>> solve this task:
>> A) most of the devices that are connected using UART have user space
>> program that configures and manages it (either directly or with help
>> of dedicated line discipline, SLIP, SL-CAN, etc)
>> B) serio - mostly used for input devices
>> C) direct use of UART port taking control from serial_core.
>>
>> The best match I have found so far is MFD driver for Atmel
>> Microcontroller on iPaq h3xxx (drivers/mfd/ipaq-micro.c) that follows
>> concept "C)"
>
> There's also D) TTY slave device support: https://lkml.org/lkml/2015/3/18/40
>
> Unfortunately this hasn't made it to mainline yet and it seems the
> parties lost interest after some lengthy discussion of device tree phandles
> vs. subnodes, but I think this is what you're looking for.
Thank you for pointing out to another option. Looks like it was developed a little further and was submitted as patch by "H. Nikolaus Schaller",
https://lkml.org/lkml/2015/10/16/729
But I see no further traces of it.
Cc'ed Nikolaus, may be he could comment on state of UART slave patch.
Best regards,
Andrey
>
> Sascha
>
^ permalink raw reply
* Re: MFD device driver on top of UART/RS232
From: Sascha Hauer @ 2015-11-17 7:53 UTC (permalink / raw)
To: Andrey Vostrikov; +Cc: linux-serial, linux-embedded, NeilBrown
In-Reply-To: <564A035A.3050108@gmail.com>
Hi Andrey,
+Cc NeilBrown <neil@brown.name>
On Mon, Nov 16, 2015 at 07:24:58PM +0300, Andrey Vostrikov wrote:
> Hi,
>
> I have an embedded system with microcontroller connected via
> UART/RS232 port. This microcontroller implements several low-level
> functions that need to be exposed as device drivers in other
> subsystems (watchdog, LEDs, HWMON, firmware read/write).
>
> I checked many drivers implemented in the kernel, searched through
> mail list archives and it looks like there are three different ways to
> solve this task:
> A) most of the devices that are connected using UART have user space
> program that configures and manages it (either directly or with help
> of dedicated line discipline, SLIP, SL-CAN, etc)
> B) serio - mostly used for input devices
> C) direct use of UART port taking control from serial_core.
>
> The best match I have found so far is MFD driver for Atmel
> Microcontroller on iPaq h3xxx (drivers/mfd/ipaq-micro.c) that follows
> concept "C)"
There's also D) TTY slave device support: https://lkml.org/lkml/2015/3/18/40
Unfortunately this hasn't made it to mainline yet and it seems the
parties lost interest after some lengthy discussion of device tree phandles
vs. subnodes, but I think this is what you're looking for.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* MFD device driver on top of UART/RS232
From: Andrey Vostrikov @ 2015-11-16 16:24 UTC (permalink / raw)
To: linux-serial, linux-embedded
Hi,
I have an embedded system with microcontroller connected via UART/RS232 port. This microcontroller implements several low-level functions that need to be exposed as device drivers in other subsystems (watchdog, LEDs, HWMON, firmware read/write).
I checked many drivers implemented in the kernel, searched through mail list archives and it looks like there are three different ways to solve this task:
A) most of the devices that are connected using UART have user space program that configures and manages it (either directly or with help of dedicated line discipline, SLIP, SL-CAN, etc)
B) serio - mostly used for input devices
C) direct use of UART port taking control from serial_core.
The best match I have found so far is MFD driver for Atmel Microcontroller on iPaq h3xxx (drivers/mfd/ipaq-micro.c) that follows concept "C)"
Is this a good enough example to use for this task? This platform is a legacy one so I am confused a little if new driver will fit nicely into the mainline.
It would be great if someone could point me to another example to follow or advise better way to implement MFD driver without user space involvement.
Best regards,
Andrey
^ permalink raw reply
* Re:linux-embedded在吗！(AD)
From: fcs020 @ 2015-11-08 19:13 UTC (permalink / raw)
To: linux-embedded
linux-embedded
欢迎加入爱奇艺vip分享QQ群：5650047 每天发放好几波爱奇艺vip会员，看蜀山战纪，灵魂摆渡2等热门大片不要钱！限时开放！验证码511
柯位等式；细齿锡金槭。解包？红灶老！绿色蜗牛壳？圆周梯度：石半夏？上海有园经贸有限公司/上海绿世界清洁用品有限公司；天若有情之追梦人“巴音珠日和！毛家园烧“泛酸鉴定肉汤，古恰；魏阙心恒在：平静凝固？自身免疫，树技状锆？坐等直播！荆门烟雾开。裕皇？江屈各：金华省郎惜佳辰！苍狼啸月兽甲勇：春色绕黄图？羊毛杜鹃“合面镇；普列薄荷”将军欲定远？新生儿短暂性菌群失调“平年。伫闻谠论能医国。
^ permalink raw reply
* Re: [PATCH v2] fs/binfmt_elf_fdpic.c: provide NOMMU loader for regular ELF binaries
From: Trevor Woerner @ 2015-10-30 19:39 UTC (permalink / raw)
To: Greg Ungerer, Rich Felker
Cc: linux-embedded, Paul Gortmaker, Matt Mackall, David Woodhouse,
Alexander Viro, David Howells, Oleg Endo, linux-fsdevel,
linux-kernel
In-Reply-To: <561F0ADA.40504@uclinux.org>
On 10/14/15 22:09, Greg Ungerer wrote:
> Hi Rich,
>
> On 14/10/15 01:49, Rich Felker wrote:
>> On Tue, Oct 13, 2015 at 10:55:45PM +1000, Greg Ungerer wrote:
>>> Hi Rich,
>>>
>>> On 09/10/15 02:38, Rich Felker wrote:
>>> It would be good to get some testing and verification on other
>>> fdpic supported arches (frv or blackfin or microblaze for example).
>> I wasn't aware Microblaze had an FDPIC ABI; are you sure it does?
What about ARM Cortex-M?
https://sfo15.pathable.com/mobile/meetings/303078
^ permalink raw reply
* Re: [PATCH v2] fs/binfmt_elf_fdpic.c: provide NOMMU loader for regular ELF binaries
From: Greg Ungerer @ 2015-10-15 2:09 UTC (permalink / raw)
To: Rich Felker
Cc: linux-embedded, Paul Gortmaker, Matt Mackall, David Woodhouse,
Alexander Viro, David Howells, Oleg Endo, linux-fsdevel,
linux-kernel
In-Reply-To: <20151013154940.GR8645@brightrain.aerifal.cx>
Hi Rich,
On 14/10/15 01:49, Rich Felker wrote:
> On Tue, Oct 13, 2015 at 10:55:45PM +1000, Greg Ungerer wrote:
>> Hi Rich,
>>
>> On 09/10/15 02:38, Rich Felker wrote:
>>> From: Rich Felker <dalias@libc.org>
>>>
>>> The ELF binary loader in binfmt_elf.c requires an MMU, making it
>>> impossible to use regular ELF binaries on NOMMU archs. However, the
>>> FDPIC ELF loader in binfmt_elf_fdpic.c is fully capable as a loader
>>> for plain ELF, which requires constant displacements between LOAD
>>> segments, since it already supports FDPIC ELF files flagged as needing
>>> constant displacement.
>>>
>>> This patch adjusts the FDPIC ELF loader to accept non-FDPIC ELF files
>>> on NOMMU archs. They are treated identically to FDPIC ELF files with
>>> the constant-displacement flag bit set, except for personality, which
>>> must match the ABI of the program being loaded; the PER_LINUX_FDPIC
>>> personality controls how the kernel interprets function pointers
>>> passed to sigaction.
>>>
>>> Files that do not set a stack size requirement explicitly are given a
>>> default stack size (matching the amount of committed stack the normal
>>> ELF loader for MMU archs would give them) rather than being rejected;
>>> this is necessary because plain ELF files generally do not declare
>>> stack requirements in theit program headers.
>>>
>>> Only ET_DYN (PIE) format ELF files are supported, since loading at a
>>> fixed virtual address is not possible on NOMMU.
>>>
>>> Signed-off-by: Rich Felker <dalias@libc.org>
>>
>> I have no problem with this, so from me:
>>
>> Acked-by: Greg Ungerer <gerg@uclinux.org>
>
> Thanks!
>
>>> ---
>>>
>>> This patch was developed and tested on J2 (SH2-compatible) but should
>>> be usable immediately on all archs where binfmt_elf_fdpic is
>>> available. Moreover, by providing dummy definitions of the
>>> elf_check_fdpic() and elf_check_const_displacement() macros for archs
>>> which lack an FDPIC ABI, it should be possible to enable building of
>>> binfmt_elf_fdpic on all other NOMMU archs and thereby give them ELF
>>> binary support, but I have not yet tested this.
>>
>> There is a couple of other details that will currently stop this from
>> working on other arches too.
>>
>> .. kernel/ptrace.c has some fdpic specific code (wanting PTRACE_GETFDPIC)
>> .. arch specific mm_context_t may not have members
>> ‘interp_fdpic_loadmap' or 'exec_fdpic_loadmap'
>>
>> Should be easy to fix those.
>
> I see. For archs that lack an FDPIC ABI, I'm not sure it makes sense
> to add these things unless/until someone developes an FDPIC ABI. Would
Ok. I was looking at it from the point of view of supoporting ELF
on m68k/coldfire, that doesn't currently support FDPIC. So bypassing
FDPIC support completely.
> it instead make sense to add a new kconfig switch
> CONFIG_BINFMT_ELF_NOMMU ("NOMMU ELF loader") that's implied-on by
> CONFIG_BINFMT_ELF_FDPIC but that can also be enabled independently on
> archs where CONFIG_BINFMT_ELF_FDPIC is not available?
Yes that may be the only answer here.
> Right now these are just ideas. Unless there's a quick and easy
> decision to be made, I'd like it if we could move forward with the
> current patch (which only offers the feature on archs where
> CONFIG_BINFMT_ELF_FDPIC is already available) first and continue to
> explore options for making this available to other archs separately.
Oh, yes. No problem with that. Looks like Andrew has picked it
up. So all good there.
>> It would be good to get some testing and verification on other
>> fdpic supported arches (frv or blackfin or microblaze for example).
>
> I wasn't aware Microblaze had an FDPIC ABI; are you sure it does?
Sorry, my mistake. No microblaze FDPIC as far as I know.
Regards
Greg
> Testing to make sure these aren't broken by the patch shouldn't be
> hard to do; I'll start looking into getting a setup for it or finding
> someone who has one. If you want to also test non-FDPIC ELF binaries,
> I think just using the ELF output of a bFLT toolchain without running
> elf2flt may work as a test case, but I'm not sure. Alternatively, any
> FDPIC binary linked with -pie that doesn't use signals can run as a
> non-FDPIC one just by clearing the FDPIC bit in the header.
>
> Rich
>
^ permalink raw reply
* Re: [PATCH v2] fs/binfmt_elf_fdpic.c: provide NOMMU loader for regular ELF binaries
From: Rich Felker @ 2015-10-13 15:49 UTC (permalink / raw)
To: Greg Ungerer
Cc: linux-embedded, Paul Gortmaker, Matt Mackall, David Woodhouse,
Alexander Viro, David Howells, Oleg Endo, linux-fsdevel,
linux-kernel
In-Reply-To: <561CFF51.40909@uclinux.org>
On Tue, Oct 13, 2015 at 10:55:45PM +1000, Greg Ungerer wrote:
> Hi Rich,
>
> On 09/10/15 02:38, Rich Felker wrote:
> >From: Rich Felker <dalias@libc.org>
> >
> >The ELF binary loader in binfmt_elf.c requires an MMU, making it
> >impossible to use regular ELF binaries on NOMMU archs. However, the
> >FDPIC ELF loader in binfmt_elf_fdpic.c is fully capable as a loader
> >for plain ELF, which requires constant displacements between LOAD
> >segments, since it already supports FDPIC ELF files flagged as needing
> >constant displacement.
> >
> >This patch adjusts the FDPIC ELF loader to accept non-FDPIC ELF files
> >on NOMMU archs. They are treated identically to FDPIC ELF files with
> >the constant-displacement flag bit set, except for personality, which
> >must match the ABI of the program being loaded; the PER_LINUX_FDPIC
> >personality controls how the kernel interprets function pointers
> >passed to sigaction.
> >
> >Files that do not set a stack size requirement explicitly are given a
> >default stack size (matching the amount of committed stack the normal
> >ELF loader for MMU archs would give them) rather than being rejected;
> >this is necessary because plain ELF files generally do not declare
> >stack requirements in theit program headers.
> >
> >Only ET_DYN (PIE) format ELF files are supported, since loading at a
> >fixed virtual address is not possible on NOMMU.
> >
> >Signed-off-by: Rich Felker <dalias@libc.org>
>
> I have no problem with this, so from me:
>
> Acked-by: Greg Ungerer <gerg@uclinux.org>
Thanks!
> >---
> >
> >This patch was developed and tested on J2 (SH2-compatible) but should
> >be usable immediately on all archs where binfmt_elf_fdpic is
> >available. Moreover, by providing dummy definitions of the
> >elf_check_fdpic() and elf_check_const_displacement() macros for archs
> >which lack an FDPIC ABI, it should be possible to enable building of
> >binfmt_elf_fdpic on all other NOMMU archs and thereby give them ELF
> >binary support, but I have not yet tested this.
>
> There is a couple of other details that will currently stop this from
> working on other arches too.
>
> .. kernel/ptrace.c has some fdpic specific code (wanting PTRACE_GETFDPIC)
> .. arch specific mm_context_t may not have members
> ‘interp_fdpic_loadmap' or 'exec_fdpic_loadmap'
>
> Should be easy to fix those.
I see. For archs that lack an FDPIC ABI, I'm not sure it makes sense
to add these things unless/until someone developes an FDPIC ABI. Would
it instead make sense to add a new kconfig switch
CONFIG_BINFMT_ELF_NOMMU ("NOMMU ELF loader") that's implied-on by
CONFIG_BINFMT_ELF_FDPIC but that can also be enabled independently on
archs where CONFIG_BINFMT_ELF_FDPIC is not available?
Right now these are just ideas. Unless there's a quick and easy
decision to be made, I'd like it if we could move forward with the
current patch (which only offers the feature on archs where
CONFIG_BINFMT_ELF_FDPIC is already available) first and continue to
explore options for making this available to other archs separately.
> It would be good to get some testing and verification on other
> fdpic supported arches (frv or blackfin or microblaze for example).
I wasn't aware Microblaze had an FDPIC ABI; are you sure it does?
Testing to make sure these aren't broken by the patch shouldn't be
hard to do; I'll start looking into getting a setup for it or finding
someone who has one. If you want to also test non-FDPIC ELF binaries,
I think just using the ELF output of a bFLT toolchain without running
elf2flt may work as a test case, but I'm not sure. Alternatively, any
FDPIC binary linked with -pie that doesn't use signals can run as a
non-FDPIC one just by clearing the FDPIC bit in the header.
Rich
^ permalink raw reply
* Re: [PATCH v2] fs/binfmt_elf_fdpic.c: provide NOMMU loader for regular ELF binaries
From: Greg Ungerer @ 2015-10-13 12:55 UTC (permalink / raw)
To: Rich Felker, linux-embedded
Cc: Paul Gortmaker, Matt Mackall, David Woodhouse, Alexander Viro,
David Howells, Oleg Endo, linux-fsdevel, linux-kernel
In-Reply-To: <20151008163810.GX8645@brightrain.aerifal.cx>
Hi Rich,
On 09/10/15 02:38, Rich Felker wrote:
> From: Rich Felker <dalias@libc.org>
>
> The ELF binary loader in binfmt_elf.c requires an MMU, making it
> impossible to use regular ELF binaries on NOMMU archs. However, the
> FDPIC ELF loader in binfmt_elf_fdpic.c is fully capable as a loader
> for plain ELF, which requires constant displacements between LOAD
> segments, since it already supports FDPIC ELF files flagged as needing
> constant displacement.
>
> This patch adjusts the FDPIC ELF loader to accept non-FDPIC ELF files
> on NOMMU archs. They are treated identically to FDPIC ELF files with
> the constant-displacement flag bit set, except for personality, which
> must match the ABI of the program being loaded; the PER_LINUX_FDPIC
> personality controls how the kernel interprets function pointers
> passed to sigaction.
>
> Files that do not set a stack size requirement explicitly are given a
> default stack size (matching the amount of committed stack the normal
> ELF loader for MMU archs would give them) rather than being rejected;
> this is necessary because plain ELF files generally do not declare
> stack requirements in theit program headers.
>
> Only ET_DYN (PIE) format ELF files are supported, since loading at a
> fixed virtual address is not possible on NOMMU.
>
> Signed-off-by: Rich Felker <dalias@libc.org>
I have no problem with this, so from me:
Acked-by: Greg Ungerer <gerg@uclinux.org>
> ---
>
> This patch was developed and tested on J2 (SH2-compatible) but should
> be usable immediately on all archs where binfmt_elf_fdpic is
> available. Moreover, by providing dummy definitions of the
> elf_check_fdpic() and elf_check_const_displacement() macros for archs
> which lack an FDPIC ABI, it should be possible to enable building of
> binfmt_elf_fdpic on all other NOMMU archs and thereby give them ELF
> binary support, but I have not yet tested this.
There is a couple of other details that will currently stop this from
working on other arches too.
. kernel/ptrace.c has some fdpic specific code (wanting PTRACE_GETFDPIC)
. arch specific mm_context_t may not have members ‘interp_fdpic_loadmap'
or 'exec_fdpic_loadmap'
Should be easy to fix those.
It would be good to get some testing and verification on other
fdpic supported arches (frv or blackfin or microblaze for example).
Regards
Greg
> The motivation for using binfmt_elf_fdpic.c rather than adapting
> binfmt_elf.c to NOMMU is that the former already has all the necessary
> code to work properly on NOMMU and has already received widespread
> real-world use and testing. I hope this is not controversial.
>
> I'm not really happy with having to unset the FDPIC_FUNCPTRS
> personality bit when loading non-FDPIC ELF. This bit should really
> reset automatically on execve, since otherwise, executing non-ELF
> binaries (e.g. bFLT) from an FDPIC process will leave the personality
> in the wrong state and severely break signal handling. But that's a
> separate, existing bug and I don't know the right place to fix it.
>
> The previous version of this patch had a bug which broke loading of
> non-ET_DYN FDPIC binaries that slipped through my testing. This
> version fixes the regression and has been tested with both FDPIC and
> non-FDPIC ELF files.
>
>
> --- fs/binfmt_elf_fdpic.c.orig 2015-09-29 22:13:06.716412478 +0000
> +++ fs/binfmt_elf_fdpic.c 2015-10-07 05:11:33.702236056 +0000
> @@ -103,19 +103,36 @@
> core_initcall(init_elf_fdpic_binfmt);
> module_exit(exit_elf_fdpic_binfmt);
>
> -static int is_elf_fdpic(struct elfhdr *hdr, struct file *file)
> +static int is_elf(struct elfhdr *hdr, struct file *file)
> {
> if (memcmp(hdr->e_ident, ELFMAG, SELFMAG) != 0)
> return 0;
> if (hdr->e_type != ET_EXEC && hdr->e_type != ET_DYN)
> return 0;
> - if (!elf_check_arch(hdr) || !elf_check_fdpic(hdr))
> + if (!elf_check_arch(hdr))
> return 0;
> if (!file->f_op->mmap)
> return 0;
> return 1;
> }
>
> +#ifndef elf_check_fdpic
> +#define elf_check_fdpic(x) 0
> +#endif
> +
> +#ifndef elf_check_const_displacement
> +#define elf_check_const_displacement(x) 0
> +#endif
> +
> +static int is_constdisp(struct elfhdr *hdr)
> +{
> + if (!elf_check_fdpic(hdr))
> + return 1;
> + if (elf_check_const_displacement(hdr))
> + return 1;
> + return 0;
> +}
> +
> /*****************************************************************************/
> /*
> * read the program headers table into memory
> @@ -191,8 +208,18 @@
>
> /* check that this is a binary we know how to deal with */
> retval = -ENOEXEC;
> - if (!is_elf_fdpic(&exec_params.hdr, bprm->file))
> + if (!is_elf(&exec_params.hdr, bprm->file))
> goto error;
> + if (!elf_check_fdpic(&exec_params.hdr)) {
> +#ifdef CONFIG_MMU
> + /* binfmt_elf handles non-fdpic elf except on nommu */
> + goto error;
> +#else
> + /* nommu can only load ET_DYN (PIE) ELF */
> + if (exec_params.hdr.e_type != ET_DYN)
> + goto error;
> +#endif
> + }
>
> /* read the program header table */
> retval = elf_fdpic_fetch_phdrs(&exec_params, bprm->file);
> @@ -269,13 +296,13 @@
>
> }
>
> - if (elf_check_const_displacement(&exec_params.hdr))
> + if (is_constdisp(&exec_params.hdr))
> exec_params.flags |= ELF_FDPIC_FLAG_CONSTDISP;
>
> /* perform insanity checks on the interpreter */
> if (interpreter_name) {
> retval = -ELIBBAD;
> - if (!is_elf_fdpic(&interp_params.hdr, interpreter))
> + if (!is_elf(&interp_params.hdr, interpreter))
> goto error;
>
> interp_params.flags = ELF_FDPIC_FLAG_PRESENT;
> @@ -306,9 +333,9 @@
>
> retval = -ENOEXEC;
> if (stack_size == 0)
> - goto error;
> + stack_size = 131072UL; /* same as exec.c's default commit */
>
> - if (elf_check_const_displacement(&interp_params.hdr))
> + if (is_constdisp(&interp_params.hdr))
> interp_params.flags |= ELF_FDPIC_FLAG_CONSTDISP;
>
> /* flush all traces of the currently running executable */
> @@ -319,7 +346,10 @@
> /* there's now no turning back... the old userspace image is dead,
> * defunct, deceased, etc.
> */
> - set_personality(PER_LINUX_FDPIC);
> + if (elf_check_fdpic(&exec_params.hdr))
> + set_personality(PER_LINUX_FDPIC);
> + else
> + set_personality(PER_LINUX);
> if (elf_read_implies_exec(&exec_params.hdr, executable_stack))
> current->personality |= READ_IMPLIES_EXEC;
>
>
^ permalink raw reply
* [PATCH v2] fs/binfmt_elf_fdpic.c: provide NOMMU loader for regular ELF binaries
From: Rich Felker @ 2015-10-08 16:38 UTC (permalink / raw)
To: linux-embedded
Cc: Greg Ungerer, Paul Gortmaker, Matt Mackall, David Woodhouse,
Alexander Viro, David Howells, Oleg Endo, linux-fsdevel,
linux-kernel
From: Rich Felker <dalias@libc.org>
The ELF binary loader in binfmt_elf.c requires an MMU, making it
impossible to use regular ELF binaries on NOMMU archs. However, the
FDPIC ELF loader in binfmt_elf_fdpic.c is fully capable as a loader
for plain ELF, which requires constant displacements between LOAD
segments, since it already supports FDPIC ELF files flagged as needing
constant displacement.
This patch adjusts the FDPIC ELF loader to accept non-FDPIC ELF files
on NOMMU archs. They are treated identically to FDPIC ELF files with
the constant-displacement flag bit set, except for personality, which
must match the ABI of the program being loaded; the PER_LINUX_FDPIC
personality controls how the kernel interprets function pointers
passed to sigaction.
Files that do not set a stack size requirement explicitly are given a
default stack size (matching the amount of committed stack the normal
ELF loader for MMU archs would give them) rather than being rejected;
this is necessary because plain ELF files generally do not declare
stack requirements in theit program headers.
Only ET_DYN (PIE) format ELF files are supported, since loading at a
fixed virtual address is not possible on NOMMU.
Signed-off-by: Rich Felker <dalias@libc.org>
---
This patch was developed and tested on J2 (SH2-compatible) but should
be usable immediately on all archs where binfmt_elf_fdpic is
available. Moreover, by providing dummy definitions of the
elf_check_fdpic() and elf_check_const_displacement() macros for archs
which lack an FDPIC ABI, it should be possible to enable building of
binfmt_elf_fdpic on all other NOMMU archs and thereby give them ELF
binary support, but I have not yet tested this.
The motivation for using binfmt_elf_fdpic.c rather than adapting
binfmt_elf.c to NOMMU is that the former already has all the necessary
code to work properly on NOMMU and has already received widespread
real-world use and testing. I hope this is not controversial.
I'm not really happy with having to unset the FDPIC_FUNCPTRS
personality bit when loading non-FDPIC ELF. This bit should really
reset automatically on execve, since otherwise, executing non-ELF
binaries (e.g. bFLT) from an FDPIC process will leave the personality
in the wrong state and severely break signal handling. But that's a
separate, existing bug and I don't know the right place to fix it.
The previous version of this patch had a bug which broke loading of
non-ET_DYN FDPIC binaries that slipped through my testing. This
version fixes the regression and has been tested with both FDPIC and
non-FDPIC ELF files.
--- fs/binfmt_elf_fdpic.c.orig 2015-09-29 22:13:06.716412478 +0000
+++ fs/binfmt_elf_fdpic.c 2015-10-07 05:11:33.702236056 +0000
@@ -103,19 +103,36 @@
core_initcall(init_elf_fdpic_binfmt);
module_exit(exit_elf_fdpic_binfmt);
-static int is_elf_fdpic(struct elfhdr *hdr, struct file *file)
+static int is_elf(struct elfhdr *hdr, struct file *file)
{
if (memcmp(hdr->e_ident, ELFMAG, SELFMAG) != 0)
return 0;
if (hdr->e_type != ET_EXEC && hdr->e_type != ET_DYN)
return 0;
- if (!elf_check_arch(hdr) || !elf_check_fdpic(hdr))
+ if (!elf_check_arch(hdr))
return 0;
if (!file->f_op->mmap)
return 0;
return 1;
}
+#ifndef elf_check_fdpic
+#define elf_check_fdpic(x) 0
+#endif
+
+#ifndef elf_check_const_displacement
+#define elf_check_const_displacement(x) 0
+#endif
+
+static int is_constdisp(struct elfhdr *hdr)
+{
+ if (!elf_check_fdpic(hdr))
+ return 1;
+ if (elf_check_const_displacement(hdr))
+ return 1;
+ return 0;
+}
+
/*****************************************************************************/
/*
* read the program headers table into memory
@@ -191,8 +208,18 @@
/* check that this is a binary we know how to deal with */
retval = -ENOEXEC;
- if (!is_elf_fdpic(&exec_params.hdr, bprm->file))
+ if (!is_elf(&exec_params.hdr, bprm->file))
goto error;
+ if (!elf_check_fdpic(&exec_params.hdr)) {
+#ifdef CONFIG_MMU
+ /* binfmt_elf handles non-fdpic elf except on nommu */
+ goto error;
+#else
+ /* nommu can only load ET_DYN (PIE) ELF */
+ if (exec_params.hdr.e_type != ET_DYN)
+ goto error;
+#endif
+ }
/* read the program header table */
retval = elf_fdpic_fetch_phdrs(&exec_params, bprm->file);
@@ -269,13 +296,13 @@
}
- if (elf_check_const_displacement(&exec_params.hdr))
+ if (is_constdisp(&exec_params.hdr))
exec_params.flags |= ELF_FDPIC_FLAG_CONSTDISP;
/* perform insanity checks on the interpreter */
if (interpreter_name) {
retval = -ELIBBAD;
- if (!is_elf_fdpic(&interp_params.hdr, interpreter))
+ if (!is_elf(&interp_params.hdr, interpreter))
goto error;
interp_params.flags = ELF_FDPIC_FLAG_PRESENT;
@@ -306,9 +333,9 @@
retval = -ENOEXEC;
if (stack_size == 0)
- goto error;
+ stack_size = 131072UL; /* same as exec.c's default commit */
- if (elf_check_const_displacement(&interp_params.hdr))
+ if (is_constdisp(&interp_params.hdr))
interp_params.flags |= ELF_FDPIC_FLAG_CONSTDISP;
/* flush all traces of the currently running executable */
@@ -319,7 +346,10 @@
/* there's now no turning back... the old userspace image is dead,
* defunct, deceased, etc.
*/
- set_personality(PER_LINUX_FDPIC);
+ if (elf_check_fdpic(&exec_params.hdr))
+ set_personality(PER_LINUX_FDPIC);
+ else
+ set_personality(PER_LINUX);
if (elf_read_implies_exec(&exec_params.hdr, executable_stack))
current->personality |= READ_IMPLIES_EXEC;
^ permalink raw reply
* Re: [PATCH] fs/binfmt_elf_fdpic.c: provide NOMMU loader for regular ELF binaries
From: Rich Felker @ 2015-10-07 1:23 UTC (permalink / raw)
To: linux-embedded
Cc: Greg Ungerer, Paul Gortmaker, Matt Mackall, David Woodhouse,
Alexander Viro, David Howells, Oleg Endo, linux-fsdevel,
linux-kernel
In-Reply-To: <20150929231649.GA7821@brightrain.aerifal.cx>
Ping.
On Tue, Sep 29, 2015 at 07:16:49PM -0400, Rich Felker wrote:
> From: Rich Felker <dalias@libc.org>
>
> The ELF binary loader in binfmt_elf.c requires an MMU, making it
> impossible to use regular ELF binaries on NOMMU archs. However, the
> FDPIC ELF loader in binfmt_elf_fdpic.c is fully capable as a loader
> for plain ELF, which requires constant displacements between LOAD
> segments, since it already supports FDPIC ELF files flagged as needing
> constant displacement.
>
> This patch adjusts the FDPIC ELF loader to accept non-FDPIC ELF files
> on NOMMU archs. They are treated identically to FDPIC ELF files with
> the constant-displacement flag bit set, except for personality, which
> must match the ABI of the program being loaded; the PER_LINUX_FDPIC
> personality controls how the kernel interprets function pointers
> passed to sigaction.
>
> Files that do not set a stack size requirement explicitly are given a
> default stack size (matching the amount of committed stack the normal
> ELF loader for MMU archs would give them) rather than being rejected;
> this is necessary because plain ELF files generally do not declare
> stack requirements in theit program headers.
>
> Only ET_DYN (PIE) format ELF files are supported, since loading at a
> fixed virtual address is not possible on NOMMU.
>
> Signed-off-by: Rich Felker <dalias@libc.org>
> ---
>
> This patch was developed and tested on J2 (SH2-compatible) but should
> be usable immediately on all archs where binfmt_elf_fdpic is
> available. Moreover, by providing dummy definitions of the
> elf_check_fdpic() and elf_check_const_displacement() macros for archs
> which lack an FDPIC ABI, it should be possible to enable building of
> binfmt_elf_fdpic on all other NOMMU archs and thereby give them ELF
> binary support, but I have not yet tested this.
>
> The motivation for using binfmt_elf_fdpic.c rather than adapting
> binfmt_elf.c to NOMMU is that the former already has all the necessary
> code to work properly on NOMMU and has already received widespread
> real-world use and testing. I hope this is not controversial.
>
> I'm not really happy with having to unset the FDPIC_FUNCPTRS
> personality bit when loading non-FDPIC ELF. This bit should really
> reset automatically on execve, since otherwise, executing non-ELF
> binaries (e.g. bFLT) from an FDPIC process will leave the personality
> in the wrong state and severely break signal handling. But that's a
> separate, existing bug and I don't know the right place to fix it.
>
>
>
> --- fs/binfmt_elf_fdpic.c.orig 2015-09-29 22:13:06.716412478 +0000
> +++ fs/binfmt_elf_fdpic.c 2015-09-29 22:38:24.122986621 +0000
> @@ -103,19 +103,36 @@
> core_initcall(init_elf_fdpic_binfmt);
> module_exit(exit_elf_fdpic_binfmt);
>
> -static int is_elf_fdpic(struct elfhdr *hdr, struct file *file)
> +static int is_elf(struct elfhdr *hdr, struct file *file)
> {
> if (memcmp(hdr->e_ident, ELFMAG, SELFMAG) != 0)
> return 0;
> if (hdr->e_type != ET_EXEC && hdr->e_type != ET_DYN)
> return 0;
> - if (!elf_check_arch(hdr) || !elf_check_fdpic(hdr))
> + if (!elf_check_arch(hdr))
> return 0;
> if (!file->f_op->mmap)
> return 0;
> return 1;
> }
>
> +#ifndef elf_check_fdpic
> +#define elf_check_fdpic(x) 0
> +#endif
> +
> +#ifndef elf_check_const_displacement
> +#define elf_check_const_displacement(x) 0
> +#endif
> +
> +static int is_constdisp(struct elfhdr *hdr)
> +{
> + if (!elf_check_fdpic(hdr))
> + return 1;
> + if (elf_check_const_displacement(hdr))
> + return 1;
> + return 0;
> +}
> +
> /*****************************************************************************/
> /*
> * read the program headers table into memory
> @@ -191,8 +208,16 @@
>
> /* check that this is a binary we know how to deal with */
> retval = -ENOEXEC;
> - if (!is_elf_fdpic(&exec_params.hdr, bprm->file))
> + if (!is_elf(&exec_params.hdr, bprm->file))
> + goto error;
> +#ifdef CONFIG_MMU
> + /* binfmt_elf handles non-fdpic elf except on nommu */
> + if (!elf_check_fdpic(&exec_params.hdr))
> + goto error;
> +#else
> + if (exec_params.hdr.e_type != ET_DYN)
> goto error;
> +#endif
>
> /* read the program header table */
> retval = elf_fdpic_fetch_phdrs(&exec_params, bprm->file);
> @@ -269,13 +294,13 @@
>
> }
>
> - if (elf_check_const_displacement(&exec_params.hdr))
> + if (is_constdisp(&exec_params.hdr))
> exec_params.flags |= ELF_FDPIC_FLAG_CONSTDISP;
>
> /* perform insanity checks on the interpreter */
> if (interpreter_name) {
> retval = -ELIBBAD;
> - if (!is_elf_fdpic(&interp_params.hdr, interpreter))
> + if (!is_elf(&interp_params.hdr, interpreter))
> goto error;
>
> interp_params.flags = ELF_FDPIC_FLAG_PRESENT;
> @@ -306,9 +331,9 @@
>
> retval = -ENOEXEC;
> if (stack_size == 0)
> - goto error;
> + stack_size = 131072UL; /* same as exec.c's default commit */
>
> - if (elf_check_const_displacement(&interp_params.hdr))
> + if (is_constdisp(&interp_params.hdr))
> interp_params.flags |= ELF_FDPIC_FLAG_CONSTDISP;
>
> /* flush all traces of the currently running executable */
> @@ -319,7 +344,10 @@
> /* there's now no turning back... the old userspace image is dead,
> * defunct, deceased, etc.
> */
> - set_personality(PER_LINUX_FDPIC);
> + if (elf_check_fdpic(&exec_params.hdr))
> + set_personality(PER_LINUX_FDPIC);
> + else
> + set_personality(PER_LINUX);
> if (elf_read_implies_exec(&exec_params.hdr, executable_stack))
> current->personality |= READ_IMPLIES_EXEC;
>
^ permalink raw reply
* [PATCH] fs/binfmt_elf_fdpic.c: provide NOMMU loader for regular ELF binaries
From: Rich Felker @ 2015-09-29 23:16 UTC (permalink / raw)
To: linux-embedded
Cc: Greg Ungerer, Paul Gortmaker, Matt Mackall, David Woodhouse,
Alexander Viro, David Howells, Oleg Endo, linux-fsdevel,
linux-kernel
From: Rich Felker <dalias@libc.org>
The ELF binary loader in binfmt_elf.c requires an MMU, making it
impossible to use regular ELF binaries on NOMMU archs. However, the
FDPIC ELF loader in binfmt_elf_fdpic.c is fully capable as a loader
for plain ELF, which requires constant displacements between LOAD
segments, since it already supports FDPIC ELF files flagged as needing
constant displacement.
This patch adjusts the FDPIC ELF loader to accept non-FDPIC ELF files
on NOMMU archs. They are treated identically to FDPIC ELF files with
the constant-displacement flag bit set, except for personality, which
must match the ABI of the program being loaded; the PER_LINUX_FDPIC
personality controls how the kernel interprets function pointers
passed to sigaction.
Files that do not set a stack size requirement explicitly are given a
default stack size (matching the amount of committed stack the normal
ELF loader for MMU archs would give them) rather than being rejected;
this is necessary because plain ELF files generally do not declare
stack requirements in theit program headers.
Only ET_DYN (PIE) format ELF files are supported, since loading at a
fixed virtual address is not possible on NOMMU.
Signed-off-by: Rich Felker <dalias@libc.org>
---
This patch was developed and tested on J2 (SH2-compatible) but should
be usable immediately on all archs where binfmt_elf_fdpic is
available. Moreover, by providing dummy definitions of the
elf_check_fdpic() and elf_check_const_displacement() macros for archs
which lack an FDPIC ABI, it should be possible to enable building of
binfmt_elf_fdpic on all other NOMMU archs and thereby give them ELF
binary support, but I have not yet tested this.
The motivation for using binfmt_elf_fdpic.c rather than adapting
binfmt_elf.c to NOMMU is that the former already has all the necessary
code to work properly on NOMMU and has already received widespread
real-world use and testing. I hope this is not controversial.
I'm not really happy with having to unset the FDPIC_FUNCPTRS
personality bit when loading non-FDPIC ELF. This bit should really
reset automatically on execve, since otherwise, executing non-ELF
binaries (e.g. bFLT) from an FDPIC process will leave the personality
in the wrong state and severely break signal handling. But that's a
separate, existing bug and I don't know the right place to fix it.
--- fs/binfmt_elf_fdpic.c.orig 2015-09-29 22:13:06.716412478 +0000
+++ fs/binfmt_elf_fdpic.c 2015-09-29 22:38:24.122986621 +0000
@@ -103,19 +103,36 @@
core_initcall(init_elf_fdpic_binfmt);
module_exit(exit_elf_fdpic_binfmt);
-static int is_elf_fdpic(struct elfhdr *hdr, struct file *file)
+static int is_elf(struct elfhdr *hdr, struct file *file)
{
if (memcmp(hdr->e_ident, ELFMAG, SELFMAG) != 0)
return 0;
if (hdr->e_type != ET_EXEC && hdr->e_type != ET_DYN)
return 0;
- if (!elf_check_arch(hdr) || !elf_check_fdpic(hdr))
+ if (!elf_check_arch(hdr))
return 0;
if (!file->f_op->mmap)
return 0;
return 1;
}
+#ifndef elf_check_fdpic
+#define elf_check_fdpic(x) 0
+#endif
+
+#ifndef elf_check_const_displacement
+#define elf_check_const_displacement(x) 0
+#endif
+
+static int is_constdisp(struct elfhdr *hdr)
+{
+ if (!elf_check_fdpic(hdr))
+ return 1;
+ if (elf_check_const_displacement(hdr))
+ return 1;
+ return 0;
+}
+
/*****************************************************************************/
/*
* read the program headers table into memory
@@ -191,8 +208,16 @@
/* check that this is a binary we know how to deal with */
retval = -ENOEXEC;
- if (!is_elf_fdpic(&exec_params.hdr, bprm->file))
+ if (!is_elf(&exec_params.hdr, bprm->file))
+ goto error;
+#ifdef CONFIG_MMU
+ /* binfmt_elf handles non-fdpic elf except on nommu */
+ if (!elf_check_fdpic(&exec_params.hdr))
+ goto error;
+#else
+ if (exec_params.hdr.e_type != ET_DYN)
goto error;
+#endif
/* read the program header table */
retval = elf_fdpic_fetch_phdrs(&exec_params, bprm->file);
@@ -269,13 +294,13 @@
}
- if (elf_check_const_displacement(&exec_params.hdr))
+ if (is_constdisp(&exec_params.hdr))
exec_params.flags |= ELF_FDPIC_FLAG_CONSTDISP;
/* perform insanity checks on the interpreter */
if (interpreter_name) {
retval = -ELIBBAD;
- if (!is_elf_fdpic(&interp_params.hdr, interpreter))
+ if (!is_elf(&interp_params.hdr, interpreter))
goto error;
interp_params.flags = ELF_FDPIC_FLAG_PRESENT;
@@ -306,9 +331,9 @@
retval = -ENOEXEC;
if (stack_size == 0)
- goto error;
+ stack_size = 131072UL; /* same as exec.c's default commit */
- if (elf_check_const_displacement(&interp_params.hdr))
+ if (is_constdisp(&interp_params.hdr))
interp_params.flags |= ELF_FDPIC_FLAG_CONSTDISP;
/* flush all traces of the currently running executable */
@@ -319,7 +344,10 @@
/* there's now no turning back... the old userspace image is dead,
* defunct, deceased, etc.
*/
- set_personality(PER_LINUX_FDPIC);
+ if (elf_check_fdpic(&exec_params.hdr))
+ set_personality(PER_LINUX_FDPIC);
+ else
+ set_personality(PER_LINUX);
if (elf_read_implies_exec(&exec_params.hdr, executable_stack))
current->personality |= READ_IMPLIES_EXEC;
^ permalink raw reply
* Re: [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU
From: Greg Ungerer @ 2015-09-15 2:13 UTC (permalink / raw)
To: Rich Felker
Cc: linux-embedded, Paul Gortmaker, Matt Mackall, David Woodhouse,
Alexander Viro, linux-fsdevel, linux-kernel, David Howells
In-Reply-To: <20150914151717.GF17773@brightrain.aerifal.cx>
Hi Rich,
On 15/09/15 01:17, Rich Felker wrote:
> On Mon, Sep 14, 2015 at 10:13:03PM +1000, Greg Ungerer wrote:
>> On 26/08/15 11:26, Greg Ungerer wrote:
>>> On 21/08/15 05:11, Rich Felker wrote:
>>>> From: Rich Felker <dalias@libc.org>
>>>>
>>>> On NOMMU archs, the FDPIC ELF loader sets up the usable brk range to
>>>> overlap with all but the last PAGE_SIZE bytes of the stack. This leads
>>>> to catastrophic memory reuse/corruption if brk is used. Fix by setting
>>>> the brk area to zero size to disable its use.
>>>>
>>>> Signed-off-by: Rich Felker <dalias@libc.org>
>>>
>>> It would make sense to run this by David Howells <dhowells@redhat.com>,
>>> I think he wrote this code (added to CC list).
>>>
>>> I have no problem with it, so:
>>>
>>> Acked-by: Greg Ungerer <gerg@uclinux.org>
>>
>> Has anybody picked this up to push to Linus?
>> If not I can take it via the m68knommu tree.
>
> As far as I know, no. If you can do it that would be great.
Patch applied to m68knommu git tree (for-next branch).
(https://git.kernel.org/cgit/linux/kernel/git/gerg/m68knommu.git/)
Regards
Greg
>>>> ---
>>>>
>>>> There is no reason for the kernel to be providing a brk area at all on
>>>> NOMMU; the bFLT loader does not provide one, uClibc never uses brk on
>>>> NOMMU targets, and musl libc goes out of its way to avoid using brk
>>>> that might run into the stack.
>>>
>>> I recall a long time back someone was playing with the idea of setting
>>> the brk to the unused parts of the last data area page. (Somewhat like
>>> this code seems to be trying). That scheme still allocated the full
>>> requested stack size (IIRC) though. And that would have been on bFLT
>>> executables. Anyway, just some historical reference, not really
>>> relevant now.
>>>
>>> Regards
>>> Greg
>>>
>>>
>>>
>>>> --- fs/binfmt_elf_fdpic.c.orig 2015-08-20 18:05:19.089888654 +0000
>>>> +++ fs/binfmt_elf_fdpic.c 2015-08-20 18:10:01.519871432 +0000
>>>> @@ -374,10 +388,7 @@ static int load_elf_fdpic_binary(struct
>>>> PAGE_ALIGN(current->mm->start_brk);
>>>>
>>>> #else
>>>> - /* create a stack and brk area big enough for everyone
>>>> - * - the brk heap starts at the bottom and works up
>>>> - * - the stack starts at the top and works down
>>>> - */
>>>> + /* create a stack area and zero-size brk area */
>>>> stack_size = (stack_size + PAGE_SIZE - 1) & PAGE_MASK;
>>>> if (stack_size < PAGE_SIZE * 2)
>>>> stack_size = PAGE_SIZE * 2;
>>>> @@ -400,8 +411,6 @@ static int load_elf_fdpic_binary(struct
>>>>
>>>> current->mm->brk = current->mm->start_brk;
>>>> current->mm->context.end_brk = current->mm->start_brk;
>>>> - current->mm->context.end_brk +=
>>>> - (stack_size > PAGE_SIZE) ? (stack_size - PAGE_SIZE) : 0;
>>>> current->mm->start_stack = current->mm->start_brk + stack_size;
>>>> #endif
>>>>
>>>>
>>>
>
^ permalink raw reply
* Re: [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU
From: Rich Felker @ 2015-09-14 15:17 UTC (permalink / raw)
To: Greg Ungerer
Cc: linux-embedded, Paul Gortmaker, Matt Mackall, David Woodhouse,
Alexander Viro, linux-fsdevel, linux-kernel, David Howells
In-Reply-To: <55F6B9CF.2020206@westnet.com.au>
On Mon, Sep 14, 2015 at 10:13:03PM +1000, Greg Ungerer wrote:
> Hi Rich,
>
>
> On 26/08/15 11:26, Greg Ungerer wrote:
> >On 21/08/15 05:11, Rich Felker wrote:
> >>From: Rich Felker <dalias@libc.org>
> >>
> >>On NOMMU archs, the FDPIC ELF loader sets up the usable brk range to
> >>overlap with all but the last PAGE_SIZE bytes of the stack. This leads
> >>to catastrophic memory reuse/corruption if brk is used. Fix by setting
> >>the brk area to zero size to disable its use.
> >>
> >>Signed-off-by: Rich Felker <dalias@libc.org>
> >
> >It would make sense to run this by David Howells <dhowells@redhat.com>,
> >I think he wrote this code (added to CC list).
> >
> >I have no problem with it, so:
> >
> >Acked-by: Greg Ungerer <gerg@uclinux.org>
>
> Has anybody picked this up to push to Linus?
> If not I can take it via the m68knommu tree.
As far as I know, no. If you can do it that would be great.
Rich
> >>---
> >>
> >>There is no reason for the kernel to be providing a brk area at all on
> >>NOMMU; the bFLT loader does not provide one, uClibc never uses brk on
> >>NOMMU targets, and musl libc goes out of its way to avoid using brk
> >>that might run into the stack.
> >
> >I recall a long time back someone was playing with the idea of setting
> >the brk to the unused parts of the last data area page. (Somewhat like
> >this code seems to be trying). That scheme still allocated the full
> >requested stack size (IIRC) though. And that would have been on bFLT
> >executables. Anyway, just some historical reference, not really
> >relevant now.
> >
> >Regards
> >Greg
> >
> >
> >
> >>--- fs/binfmt_elf_fdpic.c.orig 2015-08-20 18:05:19.089888654 +0000
> >>+++ fs/binfmt_elf_fdpic.c 2015-08-20 18:10:01.519871432 +0000
> >>@@ -374,10 +388,7 @@ static int load_elf_fdpic_binary(struct
> >> PAGE_ALIGN(current->mm->start_brk);
> >>
> >> #else
> >>- /* create a stack and brk area big enough for everyone
> >>- * - the brk heap starts at the bottom and works up
> >>- * - the stack starts at the top and works down
> >>- */
> >>+ /* create a stack area and zero-size brk area */
> >> stack_size = (stack_size + PAGE_SIZE - 1) & PAGE_MASK;
> >> if (stack_size < PAGE_SIZE * 2)
> >> stack_size = PAGE_SIZE * 2;
> >>@@ -400,8 +411,6 @@ static int load_elf_fdpic_binary(struct
> >>
> >> current->mm->brk = current->mm->start_brk;
> >> current->mm->context.end_brk = current->mm->start_brk;
> >>- current->mm->context.end_brk +=
> >>- (stack_size > PAGE_SIZE) ? (stack_size - PAGE_SIZE) : 0;
> >> current->mm->start_stack = current->mm->start_brk + stack_size;
> >> #endif
> >>
> >>
> >
^ permalink raw reply
* Re: [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU
From: Greg Ungerer @ 2015-09-14 12:13 UTC (permalink / raw)
To: Rich Felker, linux-embedded
Cc: Paul Gortmaker, Matt Mackall, David Woodhouse, Alexander Viro,
linux-fsdevel, linux-kernel, David Howells
In-Reply-To: <55DD15AA.5040503@uclinux.org>
Hi Rich,
On 26/08/15 11:26, Greg Ungerer wrote:
> On 21/08/15 05:11, Rich Felker wrote:
>> From: Rich Felker <dalias@libc.org>
>>
>> On NOMMU archs, the FDPIC ELF loader sets up the usable brk range to
>> overlap with all but the last PAGE_SIZE bytes of the stack. This leads
>> to catastrophic memory reuse/corruption if brk is used. Fix by setting
>> the brk area to zero size to disable its use.
>>
>> Signed-off-by: Rich Felker <dalias@libc.org>
>
> It would make sense to run this by David Howells <dhowells@redhat.com>,
> I think he wrote this code (added to CC list).
>
> I have no problem with it, so:
>
> Acked-by: Greg Ungerer <gerg@uclinux.org>
Has anybody picked this up to push to Linus?
If not I can take it via the m68knommu tree.
Regards
Greg
>
>> ---
>>
>> There is no reason for the kernel to be providing a brk area at all on
>> NOMMU; the bFLT loader does not provide one, uClibc never uses brk on
>> NOMMU targets, and musl libc goes out of its way to avoid using brk
>> that might run into the stack.
>
> I recall a long time back someone was playing with the idea of setting
> the brk to the unused parts of the last data area page. (Somewhat like
> this code seems to be trying). That scheme still allocated the full
> requested stack size (IIRC) though. And that would have been on bFLT
> executables. Anyway, just some historical reference, not really
> relevant now.
>
> Regards
> Greg
>
>
>
>> --- fs/binfmt_elf_fdpic.c.orig 2015-08-20 18:05:19.089888654 +0000
>> +++ fs/binfmt_elf_fdpic.c 2015-08-20 18:10:01.519871432 +0000
>> @@ -374,10 +388,7 @@ static int load_elf_fdpic_binary(struct
>> PAGE_ALIGN(current->mm->start_brk);
>>
>> #else
>> - /* create a stack and brk area big enough for everyone
>> - * - the brk heap starts at the bottom and works up
>> - * - the stack starts at the top and works down
>> - */
>> + /* create a stack area and zero-size brk area */
>> stack_size = (stack_size + PAGE_SIZE - 1) & PAGE_MASK;
>> if (stack_size < PAGE_SIZE * 2)
>> stack_size = PAGE_SIZE * 2;
>> @@ -400,8 +411,6 @@ static int load_elf_fdpic_binary(struct
>>
>> current->mm->brk = current->mm->start_brk;
>> current->mm->context.end_brk = current->mm->start_brk;
>> - current->mm->context.end_brk +=
>> - (stack_size > PAGE_SIZE) ? (stack_size - PAGE_SIZE) : 0;
>> current->mm->start_stack = current->mm->start_brk + stack_size;
>> #endif
>>
>>
>
^ permalink raw reply
* Re: [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU
From: David Howells @ 2015-09-10 14:29 UTC (permalink / raw)
To: Greg Ungerer
Cc: dhowells, Rich Felker, linux-embedded, Paul Gortmaker,
Matt Mackall, David Woodhouse, Alexander Viro, linux-fsdevel,
linux-kernel
In-Reply-To: <55DD15AA.5040503@uclinux.org>
Greg Ungerer <gerg@uclinux.org> wrote:
> It would make sense to run this by David Howells <dhowells@redhat.com>,
> I think he wrote this code (added to CC list).
>
> I have no problem with it, so:
Fine by me too.
Acked-by: David Howells <dhowells@redhat.com>
^ permalink raw reply
* Re: [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU
From: Rich Felker @ 2015-08-26 2:16 UTC (permalink / raw)
To: Greg Ungerer
Cc: linux-embedded, Paul Gortmaker, Matt Mackall, David Woodhouse,
Alexander Viro, linux-fsdevel, linux-kernel, David Howells
In-Reply-To: <55DD15AA.5040503@uclinux.org>
On Wed, Aug 26, 2015 at 11:26:02AM +1000, Greg Ungerer wrote:
> Hi Rich,
>
> On 21/08/15 05:11, Rich Felker wrote:
> > From: Rich Felker <dalias@libc.org>
> >
> > On NOMMU archs, the FDPIC ELF loader sets up the usable brk range to
> > overlap with all but the last PAGE_SIZE bytes of the stack. This leads
> > to catastrophic memory reuse/corruption if brk is used. Fix by setting
> > the brk area to zero size to disable its use.
> >
> > Signed-off-by: Rich Felker <dalias@libc.org>
>
> It would make sense to run this by David Howells <dhowells@redhat.com>,
> I think he wrote this code (added to CC list).
Thanks. I have another follow-up patch to submit soon that uses the
existing ELF_FDPIC_FLAG_CONSTDISP code in binfmt_elf_fdpic.c to load
normal, non-FDPIC ELF files on NOMMU, so I'll make sure to CC him on
that too.
> I have no problem with it, so:
>
> Acked-by: Greg Ungerer <gerg@uclinux.org>
>
> > ---
> >
> > There is no reason for the kernel to be providing a brk area at all on
> > NOMMU; the bFLT loader does not provide one, uClibc never uses brk on
> > NOMMU targets, and musl libc goes out of its way to avoid using brk
> > that might run into the stack.
>
> I recall a long time back someone was playing with the idea of setting
> the brk to the unused parts of the last data area page. (Somewhat like
> this code seems to be trying). That scheme still allocated the full
> requested stack size (IIRC) though. And that would have been on bFLT
> executables. Anyway, just some historical reference, not really
> relevant now.
For what it's worth, musl's malloc rounds the initial brk up to a page
boundary, but the dynamic linker recovers any partial page at the end
of the data segment and donates it to malloc without brk's help. So
even though brk will fail and malloc will fall back to mmap, this
otherwise-wasted space does get recovered and used.
Rich
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox