Re: [PATCH V3 01/11] ARM: Disable FIQs (but not IRQs) on CPUs shutdown paths

[Russell King (Oracle)]

On Mon, Oct 17, 2022 at 11:50:05AM -0300, Guilherme G. Piccoli wrote:
> On 17/10/2022 11:17, Russell King (Oracle) wrote:
> > [...]
> >> Monthly ping - let me know if there's something I should improve in
> >> order this fix is considered!
> > 
> > Patches don't get applied unless they end up in the patch system.
> > Thanks.
> > 
> 
> Thanks Russell! Can you show me some documentation on how should I send
> the patches to this patch system? My understanding based in the
> MAINTAINERS file is that we should send the arm32 patches to you + arm ML.

Look below in my signature --.
 |
 v
-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH V3 01/11] ARM: Disable FIQs (but not IRQs) on CPUs shutdown paths

[Russell King (Oracle)]

On Mon, Oct 17, 2022 at 11:00:46AM -0300, Guilherme G. Piccoli wrote:
> On 18/09/2022 10:58, Guilherme G. Piccoli wrote:
> > On 19/08/2022 19:17, Guilherme G. Piccoli wrote:
> >> Currently the regular CPU shutdown path for ARM disables IRQs/FIQs
> >> in the secondary CPUs - smp_send_stop() calls ipi_cpu_stop(), which
> >> is responsible for that. IRQs are architecturally masked when we
> >> take an interrupt, but FIQs are high priority than IRQs, hence they
> >> aren't masked. With that said, it makes sense to disable FIQs here,
> >> but there's no need for (re-)disabling IRQs.
> >>
> >> More than that: there is an alternative path for disabling CPUs,
> >> in the form of function crash_smp_send_stop(), which is used for
> >> kexec/panic path. This function relies on a SMP call that also
> >> triggers a busy-wait loop [at machine_crash_nonpanic_core()], but
> >> without disabling FIQs. This might lead to odd scenarios, like
> >> early interrupts in the boot of kexec'd kernel or even interrupts
> >> in secondary "disabled" CPUs while the main one still works in the
> >> panic path and assumes all secondary CPUs are (really!) off.
> >>
> >> So, let's disable FIQs in both paths and *not* disable IRQs a second
> >> time, since they are already masked in both paths by the architecture.
> >> This way, we keep both CPU quiesce paths consistent and safe.
> >>
> >> Cc: Marc Zyngier 
> >> Cc: Michael Kelley 
> >> Cc: Russell King 
> >> Signed-off-by: Guilherme G. Piccoli 
> >>
> 
> Monthly ping - let me know if there's something I should improve in
> order this fix is considered!

Patches don't get applied unless they end up in the patch system.
Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 02/30] ARM: kexec: Disable IRQs/FIQs also on crash CPUs shutdown path

[Russell King (Oracle)]

On Fri, Apr 29, 2022 at 06:38:19PM -0300, Guilherme G. Piccoli wrote:
> Thanks Marc and Michael for the review/discussion.
> 
> On 29/04/2022 15:20, Marc Zyngier wrote:
> > [...]
> 
> > My expectations would be that, since we're getting here using an IPI,
> > interrupts are already masked. So what reenabled them the first place?
> > 
> > Thanks,
> > 
> > M.
> > 
> 
> Marc, I did some investigation in the code (and tried/failed in the ARM
> documentation as well heh), but this is still not 100% clear for me.
> 
> You're saying IPI calls disable IRQs/FIQs by default in the the target
> CPUs? Where does it happen? I'm a bit confused if this a processor
> mechanism, or it's in code.

When we taken an IRQ, IRQs will be masked, FIQs will not. IPIs are
themselves interrupts, so IRQs will be masked while the IPI is being
processed. Therefore, there should be no need to re-disable the
already disabled interrupts.

> But crash_smp_send_stop() is different, it seems to IPI the other CPUs
> with the flag IPI_CALL_FUNC, which leads to calling
> generic_smp_call_function_interrupt() - does it disable interrupts/FIQs
> as well? I couldn't find it.

It's buried in the architecture behaviour. When the CPU takes an
interrupt and jumps to the interrupt vector in the vectors page, it is
architecturally defined that interrupts will be disabled. If they
weren't architecturally disabled at this point, then as soon as the
first instruction is processed (at the interrupt vector, likely a
branch) the CPU would immediately take another jump to the interrupt
vector, and this process would continue indefinitely, making interrupt
handling utterly useless.

So, you won't find an explicit instruction in the code path from the
vectors to the IPI handler that disables interrupts - because it's
written into the architecture that this is what must happen.

IRQs are a lower priority than FIQs, so FIQs remain unmasked.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC PATCH 5/5] arm: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef

[Russell King (Oracle)]

On Fri, Dec 03, 2021 at 01:11:57PM +0800, Jisheng Zhang wrote:
> Replace the conditional compilation using "#ifdef CONFIG_KEXEC_CORE"
> by a check for "IS_ENABLED(CONFIG_BLK_DEV_INITRD)", to simplify the
> code and increase compile coverage.
> 
> Signed-off-by: Jisheng Zhang 

Reviewed-by: Russell King (Oracle) 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 1/1] arm: do not copy magic 4 bytes of appended DTB in zImage

[Russell King - ARM Linux admin]

On Thu, Apr 08, 2021 at 10:06:44PM +0200, Alexander Egorenkov wrote:
> If the passed zImage happens to have a DTB appended, then the magic 4 bytes
> of the DTB are copied together with the kernel image. This leads to
> failed kexec boots because the decompressor finds the aforementioned
> DTB magic and falsely tries to replace the DTB passed in the register r2
> with the non-existent appended one.
> 
> Signed-off-by: Alexander Egorenkov 

This looks correct, but I would like a comment before the assignment
of kernel_buf_size to explain that this is the size of the compressed
kernel image excluding any appended DTB.

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] arm: Increase zImage length after getting the tag

[Russell King]

On Sat, Jun 06, 2020 at 03:40:31PM +0100, Russell King wrote:
> On Sat, Jun 06, 2020 at 03:23:19PM +0200, Simon Horman wrote:
> > On Tue, Jun 02, 2020 at 12:40:34PM +0200, Łukasz Stelmach wrote:
> > > Increase the size of the zImage after seeking for the tag to avoid
> > > reading past the end of the supplied buffer should there be not tag
> > > in the zImage.
> > > 
> > > Fixes: f57f0bf8975d24fe1e7c4936fdfb5c3b123ab75f
> > > Signed-off-by: Łukasz Stelmach 
> > > Cc: Russell King 
> > 
> > Thanks Łukasz,
> 
> Sorry, I've not seen the patch, so it hasn't been reviewed.  This is the
> first I'm aware of its existence.

Found it - it's fine.

-- 
Russell King

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] arm: Increase zImage length after getting the tag

[Russell King]

On Sat, Jun 06, 2020 at 03:23:19PM +0200, Simon Horman wrote:
> On Tue, Jun 02, 2020 at 12:40:34PM +0200, Łukasz Stelmach wrote:
> > Increase the size of the zImage after seeking for the tag to avoid
> > reading past the end of the supplied buffer should there be not tag
> > in the zImage.
> > 
> > Fixes: f57f0bf8975d24fe1e7c4936fdfb5c3b123ab75f
> > Signed-off-by: Łukasz Stelmach 
> > Cc: Russell King 
> 
> Thanks Łukasz,

Sorry, I've not seen the patch, so it hasn't been reviewed.  This is the
first I'm aware of its existence.

-- 
Russell King

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec: arm: possible overwrite of initrd

[Russell King - ARM Linux admin]

On Fri, May 15, 2020 at 03:57:12PM +0200, Corentin Labbe wrote:
> Hello
> 
> Following https://lkml.org/lkml/2020/4/6/96 I was able to boot my Cubieboard4 
> via kexec reliabily.

You can try increasing the kernel size that kexec thinks the kernel
needs, but it should be extremely accurate with modern kexec.

--image-size $((0x01dc8154 + 0x1))

will add 64k on top of what you currently have.  Note where the first
figure comes from (you'll find it in the debug output, see
"Resulting kernel space").

The best I can say is try playing around with that - but, kexec's
calculations should be spot on to stop the booting kernel from
overwriting the initrd.

The only way to debug that is to get the booted kernel to hexdump the
initrd so it's possible to see what happened to it.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image

[Russell King - ARM Linux admin]

On Sun, Apr 12, 2020 at 01:35:07PM +0800, Baoquan He wrote:
> On 04/11/20 at 10:30am, Russell King - ARM Linux admin wrote:
> > On Sat, Apr 11, 2020 at 11:44:14AM +0800, Baoquan He wrote:
> > > Because We tend to use kexec_file_load more and improve/enhance it in the
> > > future, and gradually obsolete the old kexec_load interface which this
> > > patchset is trying to fix on. 
> > 
> > That's not going to happen; 32-bit ARM kexec uses the kexec_load
> > interface rather than the kexec_file_load version, and I see no one
> > with any interest in changing that - and there's users of the former.
> > 
> > I don't see how it's possible to convert 32-bit ARM kexec to the
> > kexec_file_load interface - this assumes that all you have are the
> > kernel, initrd, and commandline, but on 32-bit ARM kexec, we have
> > kernel, initrd and the dtb blob which the user can specify.
> 
> Well, I understand what you said about 32-bit ARM support with only
> kexec_old support thing. That's why I said we tend to obsolete it
> 'GRADUALLY'. It's the existing users who are using kexec_load, and the
> ARCHes which only has kexec_load, make us have to transfer to
> kexec_file_load gradually.
> 
> Comparing with kexec_load, kexec_file_load has only one disadvantage,
> that is some ARCHes only have kexec_load. Otherwise, kexec_file_load
> benefits kexec/kdump developping/maintaining very much. The loading job
> of kexec_file_load is mostly done in kernel, we can get whatever we
> want about kernel information very conveniently to do anything needed.
> For the kexec_load interface, the loading job is mostly done in
> userspace, we have to export kernel information to procfs, sysfs, etc,
> then parse them in kexec_tools, finally passed it to kernel part of
> kexec loading.
> 
> The gradual obsoleting means we may only add
> feature/improvement/enhancement to kexec_file_load. And if a bug fix is
> needed for both kexec_load and kexec_file_load, and the fix is very
> complicated, we may only fix it in kexec_file_load too. Kexec_file_load
> interface is suggested to add if does't have, just port user space part
> to kernel as x86/s390/arm64 have done.
> 
> Surely, it doesn't mean we don't fix the critical/blocker bug with
> kexec_load loading. We still try to do, just are not so eager. In the
> existing product environment, the kexec_load is used, just keep using
> it. Do we bother to change it to kexec_file_load, e.g in our RHEL7
> distros? Certainly not. But in our new product, we will change to use
> kexec_file_load interface. I guess this is similar with arm64. The
> advantage and benefit have been told in the 2nd paragraph.
> 
> 
> As for 32-bit ARM, is it like the old product, we have many in-use systems
> deployed in customers' laboratory? Wondering if ARM continues designing
> new 32-bit ARM cpu, and some companies continue producing tons of 32-bit ARM
> cpus. If yes, I think we need continue taking care of kexec_load if
> 32-bit ARM can't convert to kexec_file_load. If not, it may be not a
> barrier when we consider converting kexec_load to kexec_file_load in
> other ARCHes. We just need keep using it, try to fix those critical/blocker
> bug in kexec_load interface if encountered.
> 
> Finally, comning back to this patchset itself, the issue James spotted
> is not so ciritical, I would say. When I do kexec jumping, I will do
> loading firstly, then trigge jumping. I can think of the case that
> people may load kexec-ed kernel, then do something else, later she/he
> triggers the kexec jumping. These are not necessary steps. As Dave and I
> replied to James in the cover-letter thread, adding a systemd service of
> kexec loading, monitor hotplug uevent, reload it if any hot remove
> happened. This is quite easy to do, I don't see any problem with it, and
> why we don't do like this. 
> 
> My personal opinion, please tell if I miss anything.

All that opinion and hand waving about the benefits of the new
interface is totally irrelevent for 32-bit ARM for the reasons
I stated in my email to which you replied.

Gradual obsolecence or not, the file interface can't be supported
on 32-bit ARM as-is - it is totally inadequate and inferior as an
API compared to the functionality we have with plain kexec_load.
Without that point addressed, kexec_file_load is meaningless for
32-bit ARM.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image

[Russell King - ARM Linux admin]

On Sat, Apr 11, 2020 at 11:44:14AM +0800, Baoquan He wrote:
> Because We tend to use kexec_file_load more and improve/enhance it in the
> future, and gradually obsolete the old kexec_load interface which this
> patchset is trying to fix on. 

That's not going to happen; 32-bit ARM kexec uses the kexec_load
interface rather than the kexec_file_load version, and I see no one
with any interest in changing that - and there's users of the former.

I don't see how it's possible to convert 32-bit ARM kexec to the
kexec_file_load interface - this assumes that all you have are the
kernel, initrd, and commandline, but on 32-bit ARM kexec, we have
kernel, initrd and the dtb blob which the user can specify.

So, if we wanted to obsolete the kexec_load interface, _first_ there
needs to be a way to provide users with the existing functionality
they have already in place on 32-bit ARM - otherwise we're looking
at a userspace regression.  Especially as kexec_file_load takes
precedence on some distro patched versions of the kexec tool,
irrespective of which interface the user requests of the tool.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Trying to kexec on Allwinner A80

[Russell King - ARM Linux admin]

On Wed, Apr 08, 2020 at 05:24:12PM +0200, Corentin Labbe wrote:
> On Wed, Apr 08, 2020 at 10:33:20AM +0100, Russell King - ARM Linux admin 
> wrote:
> > On Wed, Apr 08, 2020 at 10:40:29AM +0200, Corentin Labbe wrote:
> > > This is the last boot:
> > > ## Loading init Ramdisk from Legacy Image at 2a00 ...
> > >Image Name:   
> > >Image Type:   ARM Linux RAMDisk Image (uncompressed)
> > >Data Size:8031928 Bytes = 7.7 MiB
> > >Load Address: 
> > >Entry Point:  
> > >Verifying Checksum ... OK
> > > ## Flattened Device Tree blob at 2300
> > >Booting using the fdt blob at 0x2300
> > >Loading Ramdisk to 29857000, end 29fffeb8 ... OK
> > >Loading Device Tree to 2984e000, end 29856fd1 ... OK
> > > Starting kernel ...
> > > ID:0x DT:0x2984E000
> > > Uncompressing Linux... done, booting the kernel.
> > > [...]
> > > fake uboot stuff
> > > [...]
> > > DEBUG: bootz: run kexec with --debug --kexec-syscall --force --initrd 
> > > /tmp/ramdisk --dtb /tmp/dtb --command-line='console=ttyS0,115200n8 
> > > root=/dev/ram0 earlycon=uart,mmio32,0x700 earlyprintk ip=dhcp'
> > > Set DEBUG!
> > > main:1417 OPT_KEXEC_SYSCALL
> > > main:1422 OPT_KEXEC_SYSCALL_AUTO
> > > arch_process_options:119
> > > main:1500
> > > main:1517 res=0 do_load=1
> > > main:1519 res=0 do_kexec_file_syscall=0
> > > my_load:713
> > > Try gzip decompression.
> > > kernel: 0xb6931008 kernel_size: 0x444fc8
> > > get_memory_ranges:36
> > > MEMORY RANGES
> > > 2000-9fff (0)
> > > zImage_arm_load:423
> > > zImage header: 0x016f2818 0x 0x00444fc8
> > > zImage size 0x444fc8, file size 0x444fc8
> > > zImage requires 0x00455fc8 bytes
> > >   offset 0x6738 tag 0x5a534c4b size 8
> > > Decompressed kernel sizes:
> > >  text+data 0x00b77958 bss 0x0003d428 total 0x00bb4d80
> > > Resulting kernel space: 0x00fcd920
> > > Kernel: address=0x20008000 size=0x00fcd920
> > > Initrd: address=0x20fd6000 size=0x016a6b97
> > > DT: address=0x2267d000 size=0x6043
> > > kexec_load: entry = 0x20008000 flags = 0x28
> > > nr_segments = 3
> > > segment[0].buf   = 0xb6931008
> > > segment[0].bufsz = 0x444fcc
> > > segment[0].mem   = 0x20008000
> > > segment[0].memsz = 0x445000
> > > segment[1].buf   = 0xb528a008
> > > segment[1].bufsz = 0x16a6b97
> > > segment[1].mem   = 0x20fd6000
> > > segment[1].memsz = 0x16a7000
> > > segment[2].buf   = 0x4ef88
> > > segment[2].bufsz = 0x6043
> > > segment[2].mem   = 0x2267d000
> > > segment[2].memsz = 0x7000
> > > main:1568 res=0[   32.098439] sun7i-dwmac 83.ethernet eth0: Link is 
> > > Down
> > > main:1582 res=0 do_exec=1
> > > [   32.113191] kexec_core: Starting new kernel
> > > [   32.460412] Bye!
> > > ID:0x DT:0x2267D000
> > > C:0x200080C0-0x2044CFE0->0x20B80500-0x20FC5420
> > > ID:0x DT:0x2267D000
> > > Uncompressing Linux... done, booting the kernel.
> > 
> > Okay, that looks fine:
> > - the DT is out of the way, so shouldn't be corrupted by the
> >   decompression process.
> > - the decompressor writes the kernel image to 0x20008000 to 0x20b7f958
> >   which is clear of the decompressor itself (which relocated itself
> >   to 0x20b80500).
> > - the ID doesn't matter for DT booting purposes.
> > 
> > I see you've gone back to using your own dtb rather than one derived
> > from the booting kernel. I strongly recommend against giving your own
> > dtb to kexec as if the boot loader modifies the DTB when calling the
> > first kernel (such as adding memory region information, adding MAC
> > addresses, enabling or disabling various devices) those modifications
> > will be lost if you supply your own DTB to kexec.
> > 
> > Please drop "--dtb /tmp/dtb".
> > 
> 
> Thanks it works now.
> 
> With a working setup I diffed dtb and the one given by uboot and it seems the 
> missing node for booting was /memory.

That is more or less expected - it seems kexec never adds the /memory
nodes to the dtb.  I've no idea whether it should or should not be doing
so, and is for others to thrash out the arguments for and against what
should be modified and how.

The upshot of the existing kexec behaviour is you can't take a dtb from
the kernel build and use it with kexe

Re: Trying to kexec on Allwinner A80

[Russell King - ARM Linux admin]

On Wed, Apr 08, 2020 at 10:40:29AM +0200, Corentin Labbe wrote:
> This is the last boot:
> ## Loading init Ramdisk from Legacy Image at 2a00 ...
>Image Name:   
>Image Type:   ARM Linux RAMDisk Image (uncompressed)
>Data Size:8031928 Bytes = 7.7 MiB
>Load Address: 
>Entry Point:  
>Verifying Checksum ... OK
> ## Flattened Device Tree blob at 2300
>Booting using the fdt blob at 0x2300
>Loading Ramdisk to 29857000, end 29fffeb8 ... OK
>Loading Device Tree to 2984e000, end 29856fd1 ... OK
> Starting kernel ...
> ID:0x DT:0x2984E000
> Uncompressing Linux... done, booting the kernel.
> [...]
> fake uboot stuff
> [...]
> DEBUG: bootz: run kexec with --debug --kexec-syscall --force --initrd 
> /tmp/ramdisk --dtb /tmp/dtb --command-line='console=ttyS0,115200n8 
> root=/dev/ram0 earlycon=uart,mmio32,0x700 earlyprintk ip=dhcp'
> Set DEBUG!
> main:1417 OPT_KEXEC_SYSCALL
> main:1422 OPT_KEXEC_SYSCALL_AUTO
> arch_process_options:119
> main:1500
> main:1517 res=0 do_load=1
> main:1519 res=0 do_kexec_file_syscall=0
> my_load:713
> Try gzip decompression.
> kernel: 0xb6931008 kernel_size: 0x444fc8
> get_memory_ranges:36
> MEMORY RANGES
> 2000-9fff (0)
> zImage_arm_load:423
> zImage header: 0x016f2818 0x 0x00444fc8
> zImage size 0x444fc8, file size 0x444fc8
> zImage requires 0x00455fc8 bytes
>   offset 0x6738 tag 0x5a534c4b size 8
> Decompressed kernel sizes:
>  text+data 0x00b77958 bss 0x0003d428 total 0x00bb4d80
> Resulting kernel space: 0x00fcd920
> Kernel: address=0x20008000 size=0x00fcd920
> Initrd: address=0x20fd6000 size=0x016a6b97
> DT: address=0x2267d000 size=0x6043
> kexec_load: entry = 0x20008000 flags = 0x28
> nr_segments = 3
> segment[0].buf   = 0xb6931008
> segment[0].bufsz = 0x444fcc
> segment[0].mem   = 0x20008000
> segment[0].memsz = 0x445000
> segment[1].buf   = 0xb528a008
> segment[1].bufsz = 0x16a6b97
> segment[1].mem   = 0x20fd6000
> segment[1].memsz = 0x16a7000
> segment[2].buf   = 0x4ef88
> segment[2].bufsz = 0x6043
> segment[2].mem   = 0x2267d000
> segment[2].memsz = 0x7000
> main:1568 res=0[   32.098439] sun7i-dwmac 83.ethernet eth0: Link is Down
> main:1582 res=0 do_exec=1
> [   32.113191] kexec_core: Starting new kernel
> [   32.460412] Bye!
> ID:0x DT:0x2267D000
> C:0x200080C0-0x2044CFE0->0x20B80500-0x20FC5420
> ID:0x DT:0x2267D000
> Uncompressing Linux... done, booting the kernel.

Okay, that looks fine:
- the DT is out of the way, so shouldn't be corrupted by the
  decompression process.
- the decompressor writes the kernel image to 0x20008000 to 0x20b7f958
  which is clear of the decompressor itself (which relocated itself
  to 0x20b80500).
- the ID doesn't matter for DT booting purposes.

I see you've gone back to using your own dtb rather than one derived
from the booting kernel. I strongly recommend against giving your own
dtb to kexec as if the boot loader modifies the DTB when calling the
first kernel (such as adding memory region information, adding MAC
addresses, enabling or disabling various devices) those modifications
will be lost if you supply your own DTB to kexec.

Please drop "--dtb /tmp/dtb".

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Trying to kexec on Allwinner A80

[Russell King - ARM Linux admin]

On Tue, Apr 07, 2020 at 03:48:49PM +0200, Corentin Labbe wrote:
> On Tue, Apr 07, 2020 at 02:26:02PM +0100, Russell King - ARM Linux admin 
> wrote:
> > On Tue, Apr 07, 2020 at 03:05:59PM +0200, Corentin Labbe wrote:
> > > On Tue, Apr 07, 2020 at 01:22:43PM +0100, Russell King - ARM Linux admin 
> > > wrote:
> > > > On Tue, Apr 07, 2020 at 01:34:54PM +0200, Corentin Labbe wrote:
> > > > > On Tue, Apr 07, 2020 at 11:19:12AM +0100, Russell King - ARM Linux 
> > > > > admin wrote:
> > > > > > On Tue, Apr 07, 2020 at 11:02:03AM +0100, Russell King - ARM Linux 
> > > > > > admin wrote:
> > > > > > > On Mon, Apr 06, 2020 at 10:27:20AM +0200, Corentin Labbe wrote:
> > > > > > > > Hello
> > > > > > > > 
> > > > > > > > I am trying to add the last missing Allwinner Soc in kernelci: 
> > > > > > > > the A80.
> > > > > > > > But this SoC does not have any way to be used in kernelci, no 
> > > > > > > > USB nor network in uboot.
> > > > > > > > So I have tried to fake uboot since the kernel has network 
> > > > > > > > support and run the new kernel via kexec.
> > > > > > > > 
> > > > > > > > But kexec 2.0.18 fail to work:
> > > > > > > > kexec --force /tmp/kernel --initrd /tmp/ramdisk --dtb /tmp/dtb 
> > > > > > > > --command-line='console=ttyS0,115200n8 root=/dev/ram0 
> > > > > > > > earlycon=uart,mmio32,0x700 ip=dhcp'
> > > > > > > 
> > > > > > > As I mentioned in my other reply, this apparent "kexec" command 
> > > > > > > line
> > > > > > > does not seem to reflect the arguments you actually used to invoke
> > > > > > > the kexec output below.
> > > > > > > 
> > > > > > > > syscall kexec_file_load not available.
> > > > > > > 
> > > > > > > This message is produced by do_kexec_file_load().  This function 
> > > > > > > is only
> > > > > > > invoked if the do_kexec_file_syscall flag in main() is set.  This 
> > > > > > > flag
> > > > > > > is only set if one of:
> > > > > > > 
> > > > > > >   --kexec-file-syscall
> > > > > > >   --kexec-syscall
> > > > > > >   --kexec-syscall-auto
> > > > > > >   -s
> > > > > > >   -c
> > > > > > >   -a
> > > > > > > 
> > > > > > > are provided on the kexec command line.  Your command line above 
> > > > > > > does
> > > > > > > not contain any of those arguments, so either the command line is 
> > > > > > > not
> > > > > > > what you used, or you are using a patched kexec, or your compiler 
> > > > > > > is
> > > > > > > grossly miscompiling kexec.
> > > > > > > 
> > > > > > > > Try gzip decompression.
> > > > > > > > kernel: 0xb6535008 kernel_size: 0x853200
> > > > > > > > MEMORY RANGES
> > > > > > > > 2000-9fff (0)
> > > > > > > 
> > > > > > > Then there's the debug output, which is only produced if the
> > > > > > > kexec_debug global is set, which in turn is only set if --debug 
> > > > > > > or -d
> > > > > > > is supplied on the kexec command line - which again, your kexec
> > > > > > > command line does not contain this.
> > > > > > > 
> > > > > > > > zImage header: 0x016f2818 0x 0x00853200
> > > > > > > > zImage size 0x853200, file size 0x853200
> > > > > > > > zImage requires 0x00864200 bytes
> > > > > > > >   offset 0xbae4 tag 0x5a534c4b size 8
> > > > > > > > Decompressed kernel sizes:
> > > > > > > >  text+data 0x0158b3a0 bss 0x000632f0 total 0x015ee690
> > > > > > > > Resulting kernel space: 0x01def5a0
> > > > > > > > Kernel: address=0x20008000 size=0x01def5a0
> > > > > > > > Initrd: address=0x21df8000 size=0x0090b6fa
> &

Re: Trying to kexec on Allwinner A80

[Russell King - ARM Linux admin]

On Tue, Apr 07, 2020 at 03:05:59PM +0200, Corentin Labbe wrote:
> On Tue, Apr 07, 2020 at 01:22:43PM +0100, Russell King - ARM Linux admin 
> wrote:
> > On Tue, Apr 07, 2020 at 01:34:54PM +0200, Corentin Labbe wrote:
> > > On Tue, Apr 07, 2020 at 11:19:12AM +0100, Russell King - ARM Linux admin 
> > > wrote:
> > > > On Tue, Apr 07, 2020 at 11:02:03AM +0100, Russell King - ARM Linux 
> > > > admin wrote:
> > > > > On Mon, Apr 06, 2020 at 10:27:20AM +0200, Corentin Labbe wrote:
> > > > > > Hello
> > > > > > 
> > > > > > I am trying to add the last missing Allwinner Soc in kernelci: the 
> > > > > > A80.
> > > > > > But this SoC does not have any way to be used in kernelci, no USB 
> > > > > > nor network in uboot.
> > > > > > So I have tried to fake uboot since the kernel has network support 
> > > > > > and run the new kernel via kexec.
> > > > > > 
> > > > > > But kexec 2.0.18 fail to work:
> > > > > > kexec --force /tmp/kernel --initrd /tmp/ramdisk --dtb /tmp/dtb 
> > > > > > --command-line='console=ttyS0,115200n8 root=/dev/ram0 
> > > > > > earlycon=uart,mmio32,0x700 ip=dhcp'
> > > > > 
> > > > > As I mentioned in my other reply, this apparent "kexec" command line
> > > > > does not seem to reflect the arguments you actually used to invoke
> > > > > the kexec output below.
> > > > > 
> > > > > > syscall kexec_file_load not available.
> > > > > 
> > > > > This message is produced by do_kexec_file_load().  This function is 
> > > > > only
> > > > > invoked if the do_kexec_file_syscall flag in main() is set.  This flag
> > > > > is only set if one of:
> > > > > 
> > > > >   --kexec-file-syscall
> > > > >   --kexec-syscall
> > > > >   --kexec-syscall-auto
> > > > >   -s
> > > > >   -c
> > > > >   -a
> > > > > 
> > > > > are provided on the kexec command line.  Your command line above does
> > > > > not contain any of those arguments, so either the command line is not
> > > > > what you used, or you are using a patched kexec, or your compiler is
> > > > > grossly miscompiling kexec.
> > > > > 
> > > > > > Try gzip decompression.
> > > > > > kernel: 0xb6535008 kernel_size: 0x853200
> > > > > > MEMORY RANGES
> > > > > > 2000-9fff (0)
> > > > > 
> > > > > Then there's the debug output, which is only produced if the
> > > > > kexec_debug global is set, which in turn is only set if --debug or -d
> > > > > is supplied on the kexec command line - which again, your kexec
> > > > > command line does not contain this.
> > > > > 
> > > > > > zImage header: 0x016f2818 0x 0x00853200
> > > > > > zImage size 0x853200, file size 0x853200
> > > > > > zImage requires 0x00864200 bytes
> > > > > >   offset 0xbae4 tag 0x5a534c4b size 8
> > > > > > Decompressed kernel sizes:
> > > > > >  text+data 0x0158b3a0 bss 0x000632f0 total 0x015ee690
> > > > > > Resulting kernel space: 0x01def5a0
> > > > > > Kernel: address=0x20008000 size=0x01def5a0
> > > > > > Initrd: address=0x21df8000 size=0x0090b6fa
> > > > > > DT: address=0x22704000 size=0x5c09
> > > > > > kexec_load: entry = 0x20008000 flags = 0x28
> > > > > > nr_segments = 3
> > > > > > segment[0].buf   = 0xb6535008
> > > > > > segment[0].bufsz = 0x853204
> > > > > > segment[0].mem   = 0x20008000
> > > > > > segment[0].memsz = 0x854000
> > > > > > segment[1].buf   = 0xb5c29008
> > > > > > segment[1].bufsz = 0x90b6fa
> > > > > > segment[1].mem   = 0x21df8000
> > > > > > segment[1].memsz = 0x90c000
> > > > > > segment[2].buf   = 0x4db50
> > > > > > segment[2].bufsz = 0x5c09
> > > > > > segm[   71.039126] kexec_core: Starting new kernel
> > > > > > ent[2].mem   = 0[   71.044712] Disabling non-boot CPUs ...
> > > > > > x22704000
> > > 

Re: Trying to kexec on Allwinner A80

[Russell King - ARM Linux admin]

On Tue, Apr 07, 2020 at 01:34:54PM +0200, Corentin Labbe wrote:
> On Tue, Apr 07, 2020 at 11:19:12AM +0100, Russell King - ARM Linux admin 
> wrote:
> > On Tue, Apr 07, 2020 at 11:02:03AM +0100, Russell King - ARM Linux admin 
> > wrote:
> > > On Mon, Apr 06, 2020 at 10:27:20AM +0200, Corentin Labbe wrote:
> > > > Hello
> > > > 
> > > > I am trying to add the last missing Allwinner Soc in kernelci: the A80.
> > > > But this SoC does not have any way to be used in kernelci, no USB nor 
> > > > network in uboot.
> > > > So I have tried to fake uboot since the kernel has network support and 
> > > > run the new kernel via kexec.
> > > > 
> > > > But kexec 2.0.18 fail to work:
> > > > kexec --force /tmp/kernel --initrd /tmp/ramdisk --dtb /tmp/dtb 
> > > > --command-line='console=ttyS0,115200n8 root=/dev/ram0 
> > > > earlycon=uart,mmio32,0x700 ip=dhcp'
> > > 
> > > As I mentioned in my other reply, this apparent "kexec" command line
> > > does not seem to reflect the arguments you actually used to invoke
> > > the kexec output below.
> > > 
> > > > syscall kexec_file_load not available.
> > > 
> > > This message is produced by do_kexec_file_load().  This function is only
> > > invoked if the do_kexec_file_syscall flag in main() is set.  This flag
> > > is only set if one of:
> > > 
> > >   --kexec-file-syscall
> > >   --kexec-syscall
> > >   --kexec-syscall-auto
> > >   -s
> > >   -c
> > >   -a
> > > 
> > > are provided on the kexec command line.  Your command line above does
> > > not contain any of those arguments, so either the command line is not
> > > what you used, or you are using a patched kexec, or your compiler is
> > > grossly miscompiling kexec.
> > > 
> > > > Try gzip decompression.
> > > > kernel: 0xb6535008 kernel_size: 0x853200
> > > > MEMORY RANGES
> > > > 2000-9fff (0)
> > > 
> > > Then there's the debug output, which is only produced if the
> > > kexec_debug global is set, which in turn is only set if --debug or -d
> > > is supplied on the kexec command line - which again, your kexec
> > > command line does not contain this.
> > > 
> > > > zImage header: 0x016f2818 0x 0x00853200
> > > > zImage size 0x853200, file size 0x853200
> > > > zImage requires 0x00864200 bytes
> > > >   offset 0xbae4 tag 0x5a534c4b size 8
> > > > Decompressed kernel sizes:
> > > >  text+data 0x0158b3a0 bss 0x000632f0 total 0x015ee690
> > > > Resulting kernel space: 0x01def5a0
> > > > Kernel: address=0x20008000 size=0x01def5a0
> > > > Initrd: address=0x21df8000 size=0x0090b6fa
> > > > DT: address=0x22704000 size=0x5c09
> > > > kexec_load: entry = 0x20008000 flags = 0x28
> > > > nr_segments = 3
> > > > segment[0].buf   = 0xb6535008
> > > > segment[0].bufsz = 0x853204
> > > > segment[0].mem   = 0x20008000
> > > > segment[0].memsz = 0x854000
> > > > segment[1].buf   = 0xb5c29008
> > > > segment[1].bufsz = 0x90b6fa
> > > > segment[1].mem   = 0x21df8000
> > > > segment[1].memsz = 0x90c000
> > > > segment[2].buf   = 0x4db50
> > > > segment[2].bufsz = 0x5c09
> > > > segm[   71.039126] kexec_core: Starting new kernel
> > > > ent[2].mem   = 0[   71.044712] Disabling non-boot CPUs ...
> > > > x22704000
> > > > segment[2].memsz = 0x6000
> > > > [   71.489070] Bye!
> > > > 
> > > > 
> > > > I have tried also kexec-2.0.20
> > > > Try gzip decompression.
> > > > zImage header: 0x 0x19b4 0x1000
> > > > zImage requires 0x008641c0 bytes
> > > > Could not find a free area of memory of 0x86c1c0 bytes...
> > > > Cannot load /tmp/kernel
> > > 
> > > kexec 2.0.20 doesn't appear to have changed anything to do with how
> > > allocations are done.  The above output looks even more strange and
> > > confusing.  "zImage header" is produced by debugging prints, which
> > > imply that kexec_debug was set.
> > > 
> > > However, the "MEMORY RANGES" output is missing - this has not gone
> > > away with kexec 2.0.20, it's still there, and works for me (I've
> > > just built and teste

Re: Trying to kexec on Allwinner A80

[Russell King - ARM Linux admin]

On Tue, Apr 07, 2020 at 11:02:03AM +0100, Russell King - ARM Linux admin wrote:
> On Mon, Apr 06, 2020 at 10:27:20AM +0200, Corentin Labbe wrote:
> > Hello
> > 
> > I am trying to add the last missing Allwinner Soc in kernelci: the A80.
> > But this SoC does not have any way to be used in kernelci, no USB nor 
> > network in uboot.
> > So I have tried to fake uboot since the kernel has network support and run 
> > the new kernel via kexec.
> > 
> > But kexec 2.0.18 fail to work:
> > kexec --force /tmp/kernel --initrd /tmp/ramdisk --dtb /tmp/dtb 
> > --command-line='console=ttyS0,115200n8 root=/dev/ram0 
> > earlycon=uart,mmio32,0x700 ip=dhcp'
> 
> As I mentioned in my other reply, this apparent "kexec" command line
> does not seem to reflect the arguments you actually used to invoke
> the kexec output below.
> 
> > syscall kexec_file_load not available.
> 
> This message is produced by do_kexec_file_load().  This function is only
> invoked if the do_kexec_file_syscall flag in main() is set.  This flag
> is only set if one of:
> 
>   --kexec-file-syscall
>   --kexec-syscall
>   --kexec-syscall-auto
>   -s
>   -c
>   -a
> 
> are provided on the kexec command line.  Your command line above does
> not contain any of those arguments, so either the command line is not
> what you used, or you are using a patched kexec, or your compiler is
> grossly miscompiling kexec.
> 
> > Try gzip decompression.
> > kernel: 0xb6535008 kernel_size: 0x853200
> > MEMORY RANGES
> > 2000-9fff (0)
> 
> Then there's the debug output, which is only produced if the
> kexec_debug global is set, which in turn is only set if --debug or -d
> is supplied on the kexec command line - which again, your kexec
> command line does not contain this.
> 
> > zImage header: 0x016f2818 0x 0x00853200
> > zImage size 0x853200, file size 0x853200
> > zImage requires 0x00864200 bytes
> >   offset 0xbae4 tag 0x5a534c4b size 8
> > Decompressed kernel sizes:
> >  text+data 0x0158b3a0 bss 0x000632f0 total 0x015ee690
> > Resulting kernel space: 0x01def5a0
> > Kernel: address=0x20008000 size=0x01def5a0
> > Initrd: address=0x21df8000 size=0x0090b6fa
> > DT: address=0x22704000 size=0x5c09
> > kexec_load: entry = 0x20008000 flags = 0x28
> > nr_segments = 3
> > segment[0].buf   = 0xb6535008
> > segment[0].bufsz = 0x853204
> > segment[0].mem   = 0x20008000
> > segment[0].memsz = 0x854000
> > segment[1].buf   = 0xb5c29008
> > segment[1].bufsz = 0x90b6fa
> > segment[1].mem   = 0x21df8000
> > segment[1].memsz = 0x90c000
> > segment[2].buf   = 0x4db50
> > segment[2].bufsz = 0x5c09
> > segm[   71.039126] kexec_core: Starting new kernel
> > ent[2].mem   = 0[   71.044712] Disabling non-boot CPUs ...
> > x22704000
> > segment[2].memsz = 0x6000
> > [   71.489070] Bye!
> > 
> > 
> > I have tried also kexec-2.0.20
> > Try gzip decompression.
> > zImage header: 0x 0x19b4 0x1000
> > zImage requires 0x008641c0 bytes
> > Could not find a free area of memory of 0x86c1c0 bytes...
> > Cannot load /tmp/kernel
> 
> kexec 2.0.20 doesn't appear to have changed anything to do with how
> allocations are done.  The above output looks even more strange and
> confusing.  "zImage header" is produced by debugging prints, which
> imply that kexec_debug was set.
> 
> However, the "MEMORY RANGES" output is missing - this has not gone
> away with kexec 2.0.20, it's still there, and works for me (I've
> just built and tested kexec 2.0.20).
> 
> Also, the values on the "zImage header" line are completely messed
> up; the first should be the zImage magic value and it is not - that
> suggests that the file being loaded is not a zImage file, or is
> corrupted.

Under a VM (the kernel doesn't have kexec support - but that's not a
problem, because the initial loading stages are the relevant parts
which all happen in userspace):

# build/sbin/kexec --version
kexec-tools 2.0.20
# build/sbin/kexec --debug --load virt-vmlinuz-5.4.0+
Try gzip decompression.
kernel: 0xb6a6c008 kernel_size: 0x407358
MEMORY RANGES
4000-7fff (0)
zImage header: 0x016f2818 0x 0x00407358
zImage size 0x407358, file size 0x407358
zImage requires 0x00418358 bytes
  offset 0x7178 tag 0x5a534c4b size 12
Decompressed kernel sizes:
 text+data 0x00c2ed24 bss 0x000319ec total 0x00c60710
Resulting kernel space: 0x0104707c
Kernel: address=0x40008000 size=0x0104707c
DT: address=0x41051000 size=0x0010
kexec_load: entry = 0x40008000 f

Re: Trying to kexec on Allwinner A80

[Russell King - ARM Linux admin]

On Mon, Apr 06, 2020 at 10:27:20AM +0200, Corentin Labbe wrote:
> Hello
> 
> I am trying to add the last missing Allwinner Soc in kernelci: the A80.
> But this SoC does not have any way to be used in kernelci, no USB nor network 
> in uboot.
> So I have tried to fake uboot since the kernel has network support and run 
> the new kernel via kexec.
> 
> But kexec 2.0.18 fail to work:
> kexec --force /tmp/kernel --initrd /tmp/ramdisk --dtb /tmp/dtb 
> --command-line='console=ttyS0,115200n8 root=/dev/ram0 
> earlycon=uart,mmio32,0x700 ip=dhcp'

As I mentioned in my other reply, this apparent "kexec" command line
does not seem to reflect the arguments you actually used to invoke
the kexec output below.

> syscall kexec_file_load not available.

This message is produced by do_kexec_file_load().  This function is only
invoked if the do_kexec_file_syscall flag in main() is set.  This flag
is only set if one of:

--kexec-file-syscall
--kexec-syscall
--kexec-syscall-auto
-s
-c
-a

are provided on the kexec command line.  Your command line above does
not contain any of those arguments, so either the command line is not
what you used, or you are using a patched kexec, or your compiler is
grossly miscompiling kexec.

> Try gzip decompression.
> kernel: 0xb6535008 kernel_size: 0x853200
> MEMORY RANGES
> 2000-9fff (0)

Then there's the debug output, which is only produced if the
kexec_debug global is set, which in turn is only set if --debug or -d
is supplied on the kexec command line - which again, your kexec
command line does not contain this.

> zImage header: 0x016f2818 0x 0x00853200
> zImage size 0x853200, file size 0x853200
> zImage requires 0x00864200 bytes
>   offset 0xbae4 tag 0x5a534c4b size 8
> Decompressed kernel sizes:
>  text+data 0x0158b3a0 bss 0x000632f0 total 0x015ee690
> Resulting kernel space: 0x01def5a0
> Kernel: address=0x20008000 size=0x01def5a0
> Initrd: address=0x21df8000 size=0x0090b6fa
> DT: address=0x22704000 size=0x5c09
> kexec_load: entry = 0x20008000 flags = 0x28
> nr_segments = 3
> segment[0].buf   = 0xb6535008
> segment[0].bufsz = 0x853204
> segment[0].mem   = 0x20008000
> segment[0].memsz = 0x854000
> segment[1].buf   = 0xb5c29008
> segment[1].bufsz = 0x90b6fa
> segment[1].mem   = 0x21df8000
> segment[1].memsz = 0x90c000
> segment[2].buf   = 0x4db50
> segment[2].bufsz = 0x5c09
> segm[   71.039126] kexec_core: Starting new kernel
> ent[2].mem   = 0[   71.044712] Disabling non-boot CPUs ...
> x22704000
> segment[2].memsz = 0x6000
> [   71.489070] Bye!
> 
> 
> I have tried also kexec-2.0.20
> Try gzip decompression.
> zImage header: 0x 0x19b4 0x1000
> zImage requires 0x008641c0 bytes
> Could not find a free area of memory of 0x86c1c0 bytes...
> Cannot load /tmp/kernel

kexec 2.0.20 doesn't appear to have changed anything to do with how
allocations are done.  The above output looks even more strange and
confusing.  "zImage header" is produced by debugging prints, which
imply that kexec_debug was set.

However, the "MEMORY RANGES" output is missing - this has not gone
away with kexec 2.0.20, it's still there, and works for me (I've
just built and tested kexec 2.0.20).

Also, the values on the "zImage header" line are completely messed
up; the first should be the zImage magic value and it is not - that
suggests that the file being loaded is not a zImage file, or is
corrupted.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Trying to kexec on Allwinner A80

[Russell King - ARM Linux admin]

On Tue, Apr 07, 2020 at 11:32:53AM +0200, Corentin Labbe wrote:
> On Tue, Apr 07, 2020 at 09:12:57AM +0100, Russell King - ARM Linux admin 
> wrote:
> > That was not reflected in the command lines given to kexec that you
> > quoted previously, so I'm now wondering if you're giving me the full
> > information.
> > 
> > In any case, based on the information you've supplied thus far, I have
> > no further suggetsions to make.
> > 
> 
> Sorry I have added --debug after my initial mail.
> But I am surprised that no debug output like "MEMORY RANGES" is done (like I 
> got in my first try).
> I have started to patch kexec-tools to check it, and debug is enabled.
> Furthermore, I got in locate_hole:237 memory_ranges=0.
> So the memory region in struct kexec_info is not initialized (and so cannot 
> be printed)

The memory region information is initialised by get_memory_ranges()
in kexec/arch/arm/kexec-arm.c, which reads /proc/iomem.

That is called from my_load(), which checks that info.memory_ranges
is non-zero.  If it's zero, it errors out with "Could not get memory
layout".

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Trying to kexec on Allwinner A80

[Russell King - ARM Linux admin]

On Tue, Apr 07, 2020 at 10:01:44AM +0200, Corentin Labbe wrote:
> On Tue, Apr 07, 2020 at 08:31:17AM +0100, Russell King - ARM Linux admin 
> wrote:
> > On Mon, Apr 06, 2020 at 10:10:53PM +0200, Corentin Labbe wrote:
> > > On Mon, Apr 06, 2020 at 10:37:29AM +0100, Russell King - ARM Linux admin 
> > > wrote:
> > > > On Mon, Apr 06, 2020 at 11:25:40AM +0200, Corentin Labbe wrote:
> > > > > On Mon, Apr 06, 2020 at 10:16:00AM +0100, Russell King - ARM Linux 
> > > > > admin wrote:
> > > > > > On Mon, Apr 06, 2020 at 10:27:20AM +0200, Corentin Labbe wrote:
> > > > > > > Hello
> > > > > > > 
> > > > > > > I am trying to add the last missing Allwinner Soc in kernelci: 
> > > > > > > the A80.
> > > > > > > But this SoC does not have any way to be used in kernelci, no USB 
> > > > > > > nor network in uboot.
> > > > > > > So I have tried to fake uboot since the kernel has network 
> > > > > > > support and run the new kernel via kexec.
> > > > > > > 
> > > > > > > But kexec 2.0.18 fail to work:
> > > > > > > kexec --force /tmp/kernel --initrd /tmp/ramdisk --dtb /tmp/dtb 
> > > > > > > --command-line='console=ttyS0,115200n8 root=/dev/ram0 
> > > > > > > earlycon=uart,mmio32,0x700 ip=dhcp'
> > > > > > 
> > > > > > What happens if you omit the dtb argument?
> > > > > > 
> > > > > 
> > > > > No change without dtb
> > > > > 
> > > > > I have also tried to add --mem-mim and --mem-max without any change.
> > > > > I given mem according to what I saw in /proc/iomem
> > > > > 2000-9fff : System RAM
> > > > >   20008000-207f : Kernel code
> > > > >   2090-209a0c87 : Kernel data
> > > > > So I gave --mem-min 0x3000 --mem-max 0x9fff
> > > > > Anyway, the result is always the same.
> > > > 
> > > > The next step is to enable the early debugging - first in the
> > > > decompressor - add #define DEBUG to the top of
> > > > arch/arm/boot/compressed/head.S
> > > > 
> > > > Also enable DEBUG_LL in the kernel and use earlyprintk to see if you can
> > > > get anything from the new kernel.
> > > > 
> > > 
> > > I dont know what happened, but now I always get "Could not find a free 
> > > area of memory of 0x86c1c0 bytes..." (even with kexec 2.0.18)
> > > Furthermore, I have added crashkernel=128M to the cmdlist
> > > I have verified that the reservation is working:
> > > 2000-9fff : System RAM
> > >   20008000-207f : Kernel code
> > >   2090-209a0c87 : Kernel data
> > >   4000-47ff : Crash kernel
> > > But even with this reservation, no change.
> > 
> > crashkernel is only necessary if you're loading a kenrel image to be
> > booted when the existing one has crashed. For the problem you're
> > seeing, it's an unnecessary additional change; please drop that.
> > 
> > You could try running kexec with debug enabled to see more information.
> > 
> 
> I am already running with --debug

That was not reflected in the command lines given to kexec that you
quoted previously, so I'm now wondering if you're giving me the full
information.

In any case, based on the information you've supplied thus far, I have
no further suggetsions to make.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Trying to kexec on Allwinner A80

[Russell King - ARM Linux admin]

On Mon, Apr 06, 2020 at 10:10:53PM +0200, Corentin Labbe wrote:
> On Mon, Apr 06, 2020 at 10:37:29AM +0100, Russell King - ARM Linux admin 
> wrote:
> > On Mon, Apr 06, 2020 at 11:25:40AM +0200, Corentin Labbe wrote:
> > > On Mon, Apr 06, 2020 at 10:16:00AM +0100, Russell King - ARM Linux admin 
> > > wrote:
> > > > On Mon, Apr 06, 2020 at 10:27:20AM +0200, Corentin Labbe wrote:
> > > > > Hello
> > > > > 
> > > > > I am trying to add the last missing Allwinner Soc in kernelci: the 
> > > > > A80.
> > > > > But this SoC does not have any way to be used in kernelci, no USB nor 
> > > > > network in uboot.
> > > > > So I have tried to fake uboot since the kernel has network support 
> > > > > and run the new kernel via kexec.
> > > > > 
> > > > > But kexec 2.0.18 fail to work:
> > > > > kexec --force /tmp/kernel --initrd /tmp/ramdisk --dtb /tmp/dtb 
> > > > > --command-line='console=ttyS0,115200n8 root=/dev/ram0 
> > > > > earlycon=uart,mmio32,0x700 ip=dhcp'
> > > > 
> > > > What happens if you omit the dtb argument?
> > > > 
> > > 
> > > No change without dtb
> > > 
> > > I have also tried to add --mem-mim and --mem-max without any change.
> > > I given mem according to what I saw in /proc/iomem
> > > 2000-9fff : System RAM
> > >   20008000-207f : Kernel code
> > >   2090-209a0c87 : Kernel data
> > > So I gave --mem-min 0x3000 --mem-max 0x9fff
> > > Anyway, the result is always the same.
> > 
> > The next step is to enable the early debugging - first in the
> > decompressor - add #define DEBUG to the top of
> > arch/arm/boot/compressed/head.S
> > 
> > Also enable DEBUG_LL in the kernel and use earlyprintk to see if you can
> > get anything from the new kernel.
> > 
> 
> I dont know what happened, but now I always get "Could not find a free area 
> of memory of 0x86c1c0 bytes..." (even with kexec 2.0.18)
> Furthermore, I have added crashkernel=128M to the cmdlist
> I have verified that the reservation is working:
> 2000-9fff : System RAM
>   20008000-207f : Kernel code
>   2090-209a0c87 : Kernel data
>   4000-47ff : Crash kernel
> But even with this reservation, no change.

crashkernel is only necessary if you're loading a kenrel image to be
booted when the existing one has crashed. For the problem you're
seeing, it's an unnecessary additional change; please drop that.

You could try running kexec with debug enabled to see more information.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Trying to kexec on Allwinner A80

[Russell King - ARM Linux admin]

On Mon, Apr 06, 2020 at 11:25:40AM +0200, Corentin Labbe wrote:
> On Mon, Apr 06, 2020 at 10:16:00AM +0100, Russell King - ARM Linux admin 
> wrote:
> > On Mon, Apr 06, 2020 at 10:27:20AM +0200, Corentin Labbe wrote:
> > > Hello
> > > 
> > > I am trying to add the last missing Allwinner Soc in kernelci: the A80.
> > > But this SoC does not have any way to be used in kernelci, no USB nor 
> > > network in uboot.
> > > So I have tried to fake uboot since the kernel has network support and 
> > > run the new kernel via kexec.
> > > 
> > > But kexec 2.0.18 fail to work:
> > > kexec --force /tmp/kernel --initrd /tmp/ramdisk --dtb /tmp/dtb 
> > > --command-line='console=ttyS0,115200n8 root=/dev/ram0 
> > > earlycon=uart,mmio32,0x700 ip=dhcp'
> > 
> > What happens if you omit the dtb argument?
> > 
> 
> No change without dtb
> 
> I have also tried to add --mem-mim and --mem-max without any change.
> I given mem according to what I saw in /proc/iomem
> 2000-9fff : System RAM
>   20008000-207f : Kernel code
>   2090-209a0c87 : Kernel data
> So I gave --mem-min 0x3000 --mem-max 0x9fff
> Anyway, the result is always the same.

The next step is to enable the early debugging - first in the
decompressor - add #define DEBUG to the top of
arch/arm/boot/compressed/head.S

Also enable DEBUG_LL in the kernel and use earlyprintk to see if you can
get anything from the new kernel.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Trying to kexec on Allwinner A80

[Russell King - ARM Linux admin]

On Mon, Apr 06, 2020 at 10:27:20AM +0200, Corentin Labbe wrote:
> Hello
> 
> I am trying to add the last missing Allwinner Soc in kernelci: the A80.
> But this SoC does not have any way to be used in kernelci, no USB nor network 
> in uboot.
> So I have tried to fake uboot since the kernel has network support and run 
> the new kernel via kexec.
> 
> But kexec 2.0.18 fail to work:
> kexec --force /tmp/kernel --initrd /tmp/ramdisk --dtb /tmp/dtb 
> --command-line='console=ttyS0,115200n8 root=/dev/ram0 
> earlycon=uart,mmio32,0x700 ip=dhcp'

What happens if you omit the dtb argument?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kdump in upstream kexec-tools

[Russell King]

On Wed, Apr 18, 2018 at 03:01:08PM +0200, Simon Horman wrote:
> On Tue, Apr 17, 2018 at 10:01:13AM +0100, Russell King wrote:
> > On Tue, Apr 17, 2018 at 10:20:08AM +0530, Bhupesh Sharma wrote:
> > > Hi,
> > > 
> > > I was working on improving documentation/structure of the upstream
> > > kexec-tools and I was wondering what is the purpose of the 'kdump'
> > > directory inside the kexec-tools.
> > > 
> > > This kdump utility seems to cause confusion with the 'kdump' utility
> > > present inside some distributions (for e.g.  '/usr/sbin/kdump' present
> > > inside fedora) due to the same naming convention and so we should
> > > populate/modify the kdump man page to indicate the same, so as to
> > > avoid confusion.
> > > 
> > > Presently here are the contents of this directory:
> > > 
> > > # ls kdump/
> > > kdump.8  kdump.c  Makefile
> > > 
> > > - Out of these the kdump man documentation (kdump.8) is just a
> > > placeholder as suggested by the man page documentation: "kdump - This
> > > is just a placeholder until real man page has been written"
> > > 
> > > - Looking at kdump.c :
> > > 
> > > 1. I understand that this code is mainly used to read a crashdump from
> > > memory. One can run the same using:
> > > 
> > > # kdump 
> > > 
> > > where start_addr is basically the start address of the core dump
> > > (which can also be represented via the 'elfcorehdr' environment
> > > variable being passed to the crash kernel which represents the
> > > physical address of the start of the ELF header)
> > > 
> > > 2. This tool needs READ_ONLY access to /dev/mem (so we need to set
> > > CONFIG_STRICT_DEVMEM configuration option accordingly).
> > > 
> > > 3. The code thereafter reads (via mmap) and verifies the ELF header.
> > > Subsequently it reads (via mmap) the program header.
> > > 
> > > 4. Then we collect all the notes and write on STDOUT all the headers
> > > and notes found in the crashdump collected from memory.
> > > 
> > > So, as per my understanding even in absence of (more powerful) tools
> > > like crash (or gdb), we can still go ahead and read the crashdump from
> > > memory and display all the headers and notes present in the same on
> > > standard serial out interface using this kdump utility.
> > > 
> > > This is probably a good to have feature for systems which have very
> > > simple/minimal rootfs (and I see that a few arm32 systems seem to use
> > > the same as well) or are low on memory availability.
> > > 
> > > Now, I wanted to confirm if the 'kdump' utility for reading crashdump
> > > collected from memory is still needed (as the last commit is dated
> > > back to 2016 and was done for arm32 systems). If yes, I can go ahead
> > > and enhance the kdump man page to include the description given above
> > > - so that it helps users understand how to run the tool.
> > > 
> > > Please share your opinions.
> > 
> > Firstly, please use:
> > 
> >   git://git.armlinux.org.uk/~rmk/kexec-tools.git
> > 
> > for ARM systems - this has some important fixes that aren't in the
> > mainline repository.
> 
> I apologise if this is due to omission on my part,
> can we work towards getting them in the mainline repository?

The problem on ARM was caused because you applied the wrong version of
the patches I sent out.  When I noticed and reported it, there was no
response.

My only option over that intervening six months is to provide people
with something that actually works properly on 32-bit ARM has been
to publish my own kexec-tools git tree with the appropriate fixes in.

It now contains a couple more patches than just fixing that up.

If you want to merge from the above URL, be my guest, but as far as
I'm concerned, it's been proven that sending patches for merging is
open to mistakes happening.  That wouldn't be too bad if it hadn't
taken more than six months to get your attention on this issue.

-- 
Russell King

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kdump in upstream kexec-tools

[Russell King]

On Tue, Apr 17, 2018 at 04:20:00PM +0530, Bhupesh Sharma wrote:
> For e.g I use this tool on my arm64 board as follows:
> 
> a. Read out the 'elfcorehdr' env variable passed to the crash kernel
> and pass the same as an argument to the tool:
> 
> Assuming that the 'elfcorehdr' spans the range ->
> 0xffdf-0xffdf13ff, launch the tool as -
> 
> # kdump
> Cannot find the start of the core dump
> 
> # kdump 0xffdf >> output_elf_file
> 
> # file output_elf_file
> output: ELF 64-bit LSB core file ARM aarch64, version 1 (SYSV)

The contents should basically be the same (possibly with a different
section ordering) as /proc/vmcore in the crashdump kernel.  If so,
kdump serves no useful purpose, and ends up confusing the situation
due to its inability to handle 32-bit ELF coredump files.

It seems to me that the presence of /proc/vmcore obsoletes the kdump
tool.

-- 
Russell King

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kdump in upstream kexec-tools

[Russell King]

On Tue, Apr 17, 2018 at 10:20:08AM +0530, Bhupesh Sharma wrote:
> Hi,
> 
> I was working on improving documentation/structure of the upstream
> kexec-tools and I was wondering what is the purpose of the 'kdump'
> directory inside the kexec-tools.
> 
> This kdump utility seems to cause confusion with the 'kdump' utility
> present inside some distributions (for e.g.  '/usr/sbin/kdump' present
> inside fedora) due to the same naming convention and so we should
> populate/modify the kdump man page to indicate the same, so as to
> avoid confusion.
> 
> Presently here are the contents of this directory:
> 
> # ls kdump/
> kdump.8  kdump.c  Makefile
> 
> - Out of these the kdump man documentation (kdump.8) is just a
> placeholder as suggested by the man page documentation: "kdump - This
> is just a placeholder until real man page has been written"
> 
> - Looking at kdump.c :
> 
> 1. I understand that this code is mainly used to read a crashdump from
> memory. One can run the same using:
> 
> # kdump 
> 
> where start_addr is basically the start address of the core dump
> (which can also be represented via the 'elfcorehdr' environment
> variable being passed to the crash kernel which represents the
> physical address of the start of the ELF header)
> 
> 2. This tool needs READ_ONLY access to /dev/mem (so we need to set
> CONFIG_STRICT_DEVMEM configuration option accordingly).
> 
> 3. The code thereafter reads (via mmap) and verifies the ELF header.
> Subsequently it reads (via mmap) the program header.
> 
> 4. Then we collect all the notes and write on STDOUT all the headers
> and notes found in the crashdump collected from memory.
> 
> So, as per my understanding even in absence of (more powerful) tools
> like crash (or gdb), we can still go ahead and read the crashdump from
> memory and display all the headers and notes present in the same on
> standard serial out interface using this kdump utility.
> 
> This is probably a good to have feature for systems which have very
> simple/minimal rootfs (and I see that a few arm32 systems seem to use
> the same as well) or are low on memory availability.
> 
> Now, I wanted to confirm if the 'kdump' utility for reading crashdump
> collected from memory is still needed (as the last commit is dated
> back to 2016 and was done for arm32 systems). If yes, I can go ahead
> and enhance the kdump man page to include the description given above
> - so that it helps users understand how to run the tool.
> 
> Please share your opinions.

Firstly, please use:

  git://git.armlinux.org.uk/~rmk/kexec-tools.git

for ARM systems - this has some important fixes that aren't in the
mainline repository.

I think the kdump tool is dead.  It only supports the 64-bit ELF
format, and 32-bit ARM can either be 32-bit ELF or 64-bit ELF format
coredumps, depending whether LPAE is enabled.  I've asked questions
about this, and not got anywhere, so I now recommend not using that
tool.

Have you checked whether objcopy can copy the coredump from
/proc/vmcore to the filesystem?  That would permit saving of the
coredump image for later inspection by gdb.

-- 
Russell King

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 2/2] ARM: read kernel size from zImage

[Russell King]

On Wed, Nov 01, 2017 at 09:10:36AM +0100, Simon Horman wrote:
> On Mon, Oct 23, 2017 at 11:08:34AM +0100, Russell King wrote:
> > Read the new extension data which tells the boot agent about the
> > requirements for booting the kernel image, such as how much RAM
> > will be consumed by the kernel through decompression and booting.
> > This is necessary to control the placement of the DTB and
> > compressed RAM disk to avoid these objects being corrupted.
> > 
> > Tested-by: Tony Lindgren <t...@atomide.com>
> > Signed-off-by: Russell King <r...@armlinux.org.uk>
> 
> Thanks, applied.

Thanks, since I rebased my tree, I've realised that wasn't quite the
patch I intended, but it'll do for now.

Building the latest tree gives me a new warning:

gcc -g -O2 -fno-strict-aliasing -Wall -Wstrict-prototypes -I./include 
-I./util_lib/include -Iinclude/ -I./kexec/libfdt -D_FILE_OFFSET_BITS=64 
-I./kexec/arch/arm/include  -c -MD -o kexec/kexec.o kexec/kexec.c
kexec/kexec.c: In function ■print_crashkernel_region_size■:
kexec/kexec.c:1232:9: warning: format ■%lu■ expects argument of type ■long 
unsigned int■, but argument 2 has type ■uint64_t {aka long long unsigned int}■ 
[-Wformat=]
  printf("%lu\n", (start != end) ? (end - start + 1) : 0UL);
 ^

caused by:

commit 76b31203222a9833f424e98a134603c2f840c82b
Author: Daniel Kiper <daniel.ki...@oracle.com>
Date:   Fri Feb 17 16:47:25 2017 -0600

kexec: Add option to get crash kernel region size

On 32-bit architectures, "%lu" expects an unsigned long, but uint64_t is
an unsigned long long.  On 64-bit architectures, "%lu" also expects an
unsigned long, but uint64_t is unsigned long, so there's no warning.

The problem for ARM here is that a 64-bit value is passed as an
even-odd register pair, so for the above printf, that would be r2, r3.
However, "%lu" will expect the value in the first register following
the format pointer, that being r1.  So we end up printing garbage here.

Either we use "%llu" and cast the value to an unsigned long long
(needlessly widening on 64-bit arches), or "%lu" and cast to unsigned
long (truncating) or we need a definition of the format to be used for
uint64_t types (tends to be messy.)

-- 
Russell King

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 2/2] ARM: read kernel size from zImage

[Russell King]

Read the new extension data which tells the boot agent about the
requirements for booting the kernel image, such as how much RAM
will be consumed by the kernel through decompression and booting.
This is necessary to control the placement of the DTB and
compressed RAM disk to avoid these objects being corrupted.

Tested-by: Tony Lindgren <t...@atomide.com>
Signed-off-by: Russell King <r...@armlinux.org.uk>
---
 kexec/arch/arm/kexec-zImage-arm.c | 51 ++-
 1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/kexec/arch/arm/kexec-zImage-arm.c 
b/kexec/arch/arm/kexec-zImage-arm.c
index c6ecb04..a8c40cb 100644
--- a/kexec/arch/arm/kexec-zImage-arm.c
+++ b/kexec/arch/arm/kexec-zImage-arm.c
@@ -34,6 +34,15 @@ struct zimage_header {
 #define ZIMAGE_MAGIC cpu_to_le32(0x016f2818)
uint32_t start;
uint32_t end;
+   uint32_t endian;
+
+   /* Extension to the data passed to the boot agent.  The offset
+* points at a tagged table following a similar format to the
+* ATAGs.
+*/
+   uint32_t magic2;
+#define ZIMAGE_MAGIC2 (0x45454545)
+   uint32_t extension_tag_offset;
 };
 
 struct android_image {
@@ -114,6 +123,17 @@ struct tag {
 #define byte_size(t)((t)->hdr.size << 2)
 #define tag_size(type)  ((sizeof(struct tag_header) + sizeof(struct type) + 3) 
>> 2)
 
+struct zimage_tag {
+   struct tag_header hdr;
+   union {
+#define ZIMAGE_TAG_KRNL_SIZE cpu_to_le32(0x5a534c4b)
+   struct zimage_krnl_size {
+   uint32_t size_ptr;
+   uint32_t bss_size;
+   } krnl_size;
+   } u;
+};
+
 int zImage_arm_probe(const char *UNUSED(buf), off_t UNUSED(len))
 {
/* 
@@ -434,7 +454,7 @@ int zImage_arm_load(int argc, char **argv, const char *buf, 
off_t len,
if (dtb_file)
dtb_buf = slurp_file(dtb_file, _length);
 
-   if (len > 0x34) {
+   if (len > sizeof(struct zimage_header)) {
const struct zimage_header *hdr;
off_t size;
 
@@ -460,6 +480,35 @@ int zImage_arm_load(int argc, char **argv, const char 
*buf, off_t len,
if (size < len)
len = size;
}
+
+   /* Do we have an extension table? */
+   if (hdr->magic2 == ZIMAGE_MAGIC2 && !kexec_arm_image_size) {
+   uint32_t offset = hdr->extension_tag_offset;
+   uint32_t max = len - sizeof(struct tag_header);
+   struct zimage_tag *tag;
+
+   dbgprintf("zImage has tags\n");
+
+   for (offset = hdr->extension_tag_offset;
+(tag = (void *)(buf + offset)) != NULL &&
+offset < max && byte_size(tag) &&
+   offset + byte_size(tag) < len;
+offset += byte_size(tag)) {
+   dbgprintf("  offset 0x%08x tag 0x%08x size 
%u\n",
+ offset, tag->hdr.tag, byte_size(tag));
+   if (tag->hdr.tag == ZIMAGE_TAG_KRNL_SIZE) {
+   uint32_t *p = (void *)buf +
+   tag->u.krnl_size.size_ptr;
+
+   kexec_arm_image_size =
+   get_unaligned(p) +
+   tag->u.krnl_size.bss_size;
+   }
+   }
+
+   dbgprintf("kernel image size: 0x%08x\n",
+ kexec_arm_image_size);
+   }
}
 
/* Handle android images, 2048 is the minimum page size */
-- 
2.7.4


-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 1/2] ARM: cleanup initrd and dtb handing

[Russell King]

There is no difference in the way the initrd is handled between an
ATAG-based kernel and a DTB-based kernel.  Therefore, this should be
handled identically in both cases.

Rearrange the code to achieve this.

Signed-off-by: Russell King <r...@armlinux.org.uk>
---
 kexec/arch/arm/kexec-zImage-arm.c | 116 +++---
 1 file changed, 57 insertions(+), 59 deletions(-)

diff --git a/kexec/arch/arm/kexec-zImage-arm.c 
b/kexec/arch/arm/kexec-zImage-arm.c
index 7f02b93..c6ecb04 100644
--- a/kexec/arch/arm/kexec-zImage-arm.c
+++ b/kexec/arch/arm/kexec-zImage-arm.c
@@ -24,7 +24,7 @@
 
 #define BOOT_PARAMS_SIZE 1536
 
-off_t initrd_base = 0, initrd_size = 0;
+off_t initrd_base, initrd_size;
 unsigned int kexec_arm_image_size = 0;
 unsigned long long user_page_offset = (-1ULL);
 
@@ -200,14 +200,12 @@ int create_mem32_tag(struct tag_mem32 *tag_mem32)
 
 static
 int atag_arm_load(struct kexec_info *info, unsigned long base,
-   const char *command_line, off_t command_line_len,
-   const char *initrd, off_t initrd_len, off_t initrd_off)
+   const char *command_line, off_t command_line_len, const char *initrd)
 {
struct tag *saved_tags = atag_read_tags();
char *buf;
off_t len;
struct tag *params;
-   uint32_t *initrd_start = NULL;

buf = xmalloc(getpagesize());
if (!buf) {
@@ -251,8 +249,8 @@ int atag_arm_load(struct kexec_info *info, unsigned long 
base,
if (initrd) {
params->hdr.size = tag_size(tag_initrd);
params->hdr.tag = ATAG_INITRD2;
-   initrd_start = >u.initrd.start;
-   params->u.initrd.size = initrd_len;
+   params->u.initrd.start = initrd_base;
+   params->u.initrd.size = initrd_size;
params = tag_next(params);
}
 
@@ -272,14 +270,6 @@ int atag_arm_load(struct kexec_info *info, unsigned long 
base,
 
add_segment(info, buf, len, base, len);
 
-   if (initrd) {
-   *initrd_start = locate_hole(info, initrd_len, getpagesize(),
-   initrd_off, ULONG_MAX, INT_MAX);
-   if (*initrd_start == ULONG_MAX)
-   return -1;
-   add_segment(info, initrd, initrd_len, *initrd_start, 
initrd_len);
-   }
-
return 0;
 }
 
@@ -348,6 +338,7 @@ static int setup_dtb_prop(char **bufp, off_t *sizep, int 
parentoffset,
 int zImage_arm_load(int argc, char **argv, const char *buf, off_t len,
struct kexec_info *info)
 {
+   unsigned long page_size = getpagesize();
unsigned long base, kernel_base;
unsigned int atag_offset = 0x1000; /* 4k offset from memory start */
unsigned int extra_size = 0x8000; /* TEXT_OFFSET */
@@ -513,6 +504,14 @@ int zImage_arm_load(int argc, char **argv, const char 
*buf, off_t len,
kernel_mem_size = len + 4;
 
/*
+* If the user didn't specify the size of the image, assume the
+* maximum kernel compression ratio is 4.  Note that we must
+* include space for the compressed image here as well.
+*/
+   if (!kexec_arm_image_size)
+   kexec_arm_image_size = len * 5;
+
+   /*
 * If we are loading a dump capture kernel, we need to update kernel
 * command line and also add some additional segments.
 */
@@ -562,17 +561,28 @@ int zImage_arm_load(int argc, char **argv, const char 
*buf, off_t len,
 
kernel_base = base + extra_size;
 
-   if (kexec_arm_image_size) {
-   /* If the image size was passed as command line argument,
-* use that value for determining the address for initrd,
-* atags and dtb images. page-align the given length.*/
-   initrd_base = kernel_base + _ALIGN(kexec_arm_image_size, 
getpagesize());
-   } else {
-   /* Otherwise, assume the maximum kernel compression ratio
-* is 4, and just to be safe, place ramdisk after that.
-* Note that we must include space for the compressed
-* image here as well. */
-   initrd_base = kernel_base + _ALIGN(len * 5, getpagesize());
+   /*
+* Calculate the minimum address of the initrd, which must be
+* above the memory used by the zImage while it runs.  This
+* needs to be page-size aligned.
+*/
+   initrd_base = kernel_base + _ALIGN(kexec_arm_image_size, page_size);
+
+   if (ramdisk_buf) {
+   /*
+* Find a hole to place the initrd. The crash kernel use
+* fixed address, so no check is ok.
+*/
+   if (!(info->kexec_flags & KEXEC_ON_CRASH)) {
+   initrd_base = locate_hole(info, initrd_size, page_size,
+ initrd_base,
+

Re: [PATCH] kexec:arm: support zImage with appended device tree

[Russell King]

On Tue, Jun 27, 2017 at 06:51:50PM +0900, Hoeun Ryu wrote:
> > What about the initrd?  Do you want to append that as well?
> 
> I have thought of it.
> I think It would be better to have it.
> But I think this is the first step to do so.

That is something we don't support with the kernel, and would be insane
to do so - it would mean that the very dumb decompressor would have
to relocate not only the dtb image, but also the initrd image to
some other part of memory.  It moves the appended dtb image along with
the rest of the zImage as one complete blob, but that doesn't work
so well for an appended initrd.  It will also be rather slow.

So I'd like to continue my discouragement of this entire approach and
say that kexec-tools should *not* add support for an appended DTB nor
an appended initrd.

The kernel build process gives you the kernel image and dtb file.
The appended-dtb image support that we have in the kernel is for
backwards compatibility with non-DT aware boot loaders that only
know how to deal with one or two images at boot time.

-- 
Russell King

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] kexec:arm: support zImage with appended device tree

[Russell King]

On Tue, Jun 27, 2017 at 11:36:43AM +0900, Hoeun Ryu wrote:
> We have some cases when we would like to use different dtb from the
> running system when using kexec and I think that's why kexec-tools
> supports --dtb command line option.
> 
> For example, I have the second kernel for the crash dump with different
> kernel configuration and the different dtb from the running system. I'd
> like to exclude some nodes/properties from dtb like memory reservations
> or unnecessary devices to keep the second kernel/dtb minimal.
> 
> The concatenated zImage for arm has a benefit (whether it's intended or
> not) to make it possible for users to merge multiple boot images into a
> simple single file.
> What I'd like to do is just to support the concatenated zImage so that
> users can use --load(-panic) zImage_with_dtb_from_the_running_system
> instead of --load(-panic) zImage --dtb
> different_dtb_from_the_running_system.

Don't you mean --load(-panic) zImage_with_different_dtb_from_the_running_system
?

So, what you seem to be saying is that you think it's easier for the user
to do this:

# cat zImage some-other-dtb > zImage.dtb
# kexec --load-panic zImage.dtb

rather than:

# kexec --load-panic zImage --dtb some-other-dtb

?

What about the initrd?  Do you want to append that as well?

-- 
Russell King

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] kexec:arm: support zImage with appended device tree

[Russell King]

On Fri, Jun 23, 2017 at 05:55:38PM +0900, Hoeun Ryu wrote:
> Arm linux supports zImage with appended dtb (CONFIG_ARM_APPENDED_DTB) and
> the concatenated image is generated like `cat zImage dtb > zImage_w_dtb`.

We support that only for the purpose of allowing old boot loaders that
are not DT aware to load kernels that require DT.  If it weren't for
that, we wouldn't have it.

I don't see why we should propagate this hack to other systems such as
kexec, especially when they have native DT support.

-- 
Russell King

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v1 1/4] kexec: (bugfix) calc correct end address of memory ranges in device tree

[Russell King - ARM Linux]

On Fri, Jul 29, 2016 at 10:12:26AM -0700, Geoff Levand wrote:
> On Fri, 2016-07-29 at 09:27 +0100, Russell King - ARM Linux wrote:
> 
> > So, these functions are a mess and need fixing.
> 
> Since this change isn't really related to arm64 support, I'll
> drop this patch from my series.

Do you have a case which triggers bugs in this code?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v1 1/4] kexec: (bugfix) calc correct end address of memory ranges in device tree

[Russell King - ARM Linux]

On Thu, Jul 28, 2016 at 08:54:55PM -0300, Thiago Jung Bauermann wrote:
> Am Donnerstag, 28 Juli 2016, 00:23:31 schrieb Russell King - ARM Linux:
> > Well, ARM (and the generic code I introduced for mem_ranges) follows
> > what i386, ia64, mips, s390, and sh all do with struct memory_range
> > when used for crashdump.
> > 
> > It is extremely bad for a project to have a single structure used
> > inconsistently like this - even with generic helpers, you can't be
> > sure that the right helpers are used on the right structures, and
> > it will lead to off-by-one errors all over the place.  Just don't
> > pull crap like this, it's asking for trouble - settle on one way
> > and stick to it.
> 
> Agreed. Personally, I prefer base address and size because it's unambiguous. 
> But as long as just one convention is used and the structure and helpers 
> make it clear which one they expect, it doesn't matter that much.

Indeed.

> > Given that the majority of architectures treat .end as inclusive, I
> > think ppc* and fs2dt need to conform to the convention establised by
> > the other architectures for this structure.
> 
> So do valid_memory_range and find_memory_range in kexec/kexec.c, which 
> assume struct memory_range is end-exclusive too. I'm not sure about 
> locate_hole, it seems to assume end-inclusive but it does have a line saying 
> "size = end - start".

Unfortunately, valid_memory_range() is a mess of doing this one way and
the other:

send   = sstart + segment->memsz - 1;
return valid_memory_range(info, sstart, send);
...
last = base + memsz -1;
if (!valid_memory_range(info, base, last)) {

So, callers of valid_memory_range pass a start and inclusive end address
to valid_memory_range(), and the end address becomes "send" in this
function.

/* Check to see if we are fully contained */
if ((mstart <= sstart) && (mend >= send)) {

So, this also points to an inclusive end address for mend, but the
preceding line has:

&& mend == info->memory_range[i+1].start

which doesn't, so this is buggy because it inconsistently treats the
end address as inclusive vs exclusive.

find_memory_range() looks like end-exclusive.

locate_hole() in one place treats it as end-inclusive while doing the
merge, and end-exclusive while looking for a hole.

So, these functions are a mess and need fixing.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] kexec: fix mem_regions_sort()

[Russell King]

On Wed, Jul 27, 2016 at 11:22:24PM +0530, Pratyush Anand wrote:
> Missed CCing Russell because of --suppress-cc :(
> 
> CCing now.
> 
> On Wed, Jul 27, 2016 at 11:19 PM, Pratyush Anand <pan...@redhat.com> wrote:
> > ranges->ranges is  "struct memory_range *", however each element which need
> > to be sorted is of type "struct memory_range". So, correct "size" argument
> > of qsort() as sizeof(*ranges->ranges).

Oops.  Yes, obviously correct.

Acked-by: Russell King <r...@armlinux.org.uk>

> >
> > Signed-off-by: Pratyush Anand <pan...@redhat.com>
> > Cc:Russell King <r...@arm.linux.org.uk>

Please remove this Cc while adding my Acked-by.  Thanks.

-- 
Russell King

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v1 1/4] kexec: (bugfix) calc correct end address of memory ranges in device tree

[Russell King - ARM Linux]

On Wed, Jul 27, 2016 at 07:45:13PM -0300, Thiago Jung Bauermann wrote:
> Hello,
> 
> Am Dienstag, 19 Juli 2016, 23:28:13 schrieb Geoff Levand:
> > From: AKASHI Takahiro 
> > 
> > The end address of "reg" attribute in device tree's memory should be
> > inclusive.
> 
> Actually, there's a bug/inconsistency in kexec-tools right now.
> 
> crashdump-arm.c expect usablemem_rgns.ranges[i].end to be the last byte in 
> the range, but crashdump-powerpc.c, crashdump-ppc64.c and fs2dt.c expect it 
> to be the first byte after the range.

Well, ARM (and the generic code I introduced for mem_ranges) follows
what i386, ia64, mips, s390, and sh all do with struct memory_range
when used for crashdump.

It is extremely bad for a project to have a single structure used
inconsistently like this - even with generic helpers, you can't be
sure that the right helpers are used on the right structures, and
it will lead to off-by-one errors all over the place.  Just don't
pull crap like this, it's asking for trouble - settle on one way
and stick to it.

Given that the majority of architectures treat .end as inclusive, I
think ppc* and fs2dt need to conform to the convention establised by
the other architectures for this structure.

It's also interesting to note that crashdump-powerpc has this:

/* On powerpc memory ranges in device-tree is denoted as start
 * and size rather than start and end, as is the case with
 * other architectures like i386 . Because of this when loading
 * the memory ranges in crashdump-elf.c the filesz calculation
 * [ end - start + 1 ] goes for a toss.
 *
 * To be in sync with other archs adjust the end value for
 * every crash memory range before calling the generic function
 */

for (i = 0; i < nr_ranges; i++) {
end = crash_memory_range[i].end - 1;
crash_memory_range[i].end = end;
}

to convert from powerpc end-exclusive to end-inclusive mode -
something that could be killed if it were to conform throughout
to the established convention.  Same goes for ppc64 too:

/* On ppc64 memory ranges in device-tree is denoted as start
 * and size rather than start and end, as is the case with
 * other architectures like i386 . Because of this when loading
 * the memory ranges in crashdump-elf.c the filesz calculation
 * [ end - start + 1 ] goes for a toss.
 *
 * To be in sync with other archs adjust the end value for
 * every crash memory range before calling the generic function
 */

for (i = 0; i < nr_ranges; i++) {
end = crash_memory_range[i].end - 1;
crash_memory_range[i].end = end;
}

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC 3/3] kexec: extend kexec_file_load system call

[Russell King - ARM Linux]

On Wed, Jul 20, 2016 at 11:41:35AM +, David Laight wrote:
> From: Dave Young
> > I do not think it is worth to add another syscall for extra fds.
> > We have open(2) as an example for different numbers of arguments
> > already.
> 
> Probably works 'by luck' and no one has actually thought about why.
> That ioctl() works is (probably) even more lucky.
> 
> There are ABI that use different calling conventions for varags functions
> (eg always stack all the arguments). I guess linux doesn't run on any of them.
> 
> ioctl() is a particular problem because the 'arg' might be an integer or a 
> pointer.
> Fortunately all the 64bit ABI linux uses pass the arg parameter in a register
> (and don't use different registers for pointer and data arguments).
> 
> You could have two 'libc' functions that refer to the same system call entry.
> Certainly safer than a varargs function.

Don't forget that the syscall API is not a normal C function API - it's
special, because there's little point stacking arguments on the userspace
stack and then having the kernel function try and read them off the
kernelspace stack.

If an architecture does such a thing, then it needs special veneers to
handle that (reading off the userspace stack and placing them onto the
kernelspace stack, or the arch needs to define some other method of
handling the situation.)

So, really, the actual C APIs don't matter that much - what matters more
is the definition of a sane way to pass such arguments.  Given the
extensive historical nature of open() and ioctl(), it would be completely
silly not to create something which allows these calls to work.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC 0/3] extend kexec_file_load system call

[Russell King - ARM Linux]

On Wed, Jul 20, 2016 at 01:45:42PM +1000, Balbir Singh wrote:
> > IOW, if your kernel forced signature verification, you should not be
> > able to do sig_enforce=0. If you kernel did not have
> > CONFIG_MODULE_SIG_FORCE=y, then sig_enforce should be 0 by default anyway
> > and you are not making it worse using command line.
> 
> OK.. I checked and you are right, but that is an example and there are
> other things like security=, thermal.*, nosmep, nosmap that need auditing
> for safety and might hurt the system security if used. I still think
> think that assuming you can pass any command line without breaking security
> is a broken argument.

Quite, and you don't need to run code in a privileged environment to do
any of that.

It's also not trivial to protect against: new kernels gain new arguments
which older kernels may not know about.  No matter how much protection
is built into older kernels, newer kernels can become vulnerable through
the addition of further arguments.

Also, how sure are we that there are no stack overflow issues with kernel
command line parsing?  Can we be sure that there's none?  This is
something which happens early in the kernel boot, before the full memory
protections have been set up.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC 0/3] extend kexec_file_load system call

[Russell King - ARM Linux]

On Fri, Jul 15, 2016 at 09:26:10AM -0400, Vivek Goyal wrote:
> On Fri, Jul 15, 2016 at 09:31:02AM +0200, Arnd Bergmann wrote:
> > I think that helps, as it makes the problem space correspond to that
> > of modifying the command line, but I can still come up with countless
> > attacks based on modifications of the /chosen node and/or the command
> > line, in fact it's probably easier than any other node.
> 
> I don't know anything about DTB. So here comes a very basic question. Does
> DTB allow passing an executable blob to kernel or pass the location of
> some unsigned executable code at kernel level.

DT on ARM is a description of the hardware - it can be thought of as a
set of nodes with properties attached.  The properties can describe
anything (we have documentation in Documentation/devicetree/bindings
which describes what we expect the properties to contain.)

On other architectures, DT can also contain open-firmware "functions"
but I don't think there's much support in the kernel for that - maybe
the PPC folk can reply on that point.

It is possible that someone may, at some point, decide to create a
property that points to some executable blob, but I can't think of a
reason why we should ever allow such a monstrosity in mainline kernels.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC 0/3] extend kexec_file_load system call

[Russell King - ARM Linux]

On Wed, Jul 13, 2016 at 03:13:42PM +0200, Arnd Bergmann wrote:
> On Wednesday, July 13, 2016 10:41:28 AM CEST Mark Rutland wrote:
> > The big question is whether this is a realistic case on a secure boot
> > system.
> 
> What does x86 do here? I assume changes to the command line are also
> limited.

They aren't.  You can specify /anything/ even with a fully-signed kernel
and initrd, which was one of the things I pointed out in my previous
set of responses.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC 0/3] extend kexec_file_load system call

[Russell King - ARM Linux]

On Wed, Jul 13, 2016 at 09:03:38AM -0400, Vivek Goyal wrote:
> On Wed, Jul 13, 2016 at 09:26:39AM +0100, Russell King - ARM Linux wrote:
> > Indeed - maybe Eric knows better, but I can't see any situation where
> > the dtb we load via kexec should ever affect "the bootloader", unless
> > the "kernel" that's being loaded into kexec is "the bootloader".
> > 
> > Now, going back to the more fundamental issue raised in my first reply,
> > about the kernel command line.
> > 
> > On x86, I can see that it _is_ possible for userspace to specify a
> > command line, and the kernel loading the image provides the command
> > line to the to-be-kexeced kernel with very little checking.  So, if
> > your kernel is signed, what stops the "insecure userspace" loading
> > a signed kernel but giving it an insecure rootfs and/or console?
> 
> It is not kexec specific. I could do this for regular boot too, right?
> 
> Command line options are not signed. I thought idea behind secureboot
> was to execute only trusted code and command line options don't enforce
> you to execute unsigned code.
> 
> So it sounds like different class of security problems which you are
> referring to and not necessarily covered by secureboot or signed
> kernel.

Let me give you an example.

You have a secure boot setup, where the firmware/ROM validates the boot
loader.  Good, the boot loader hasn't been tampered with.

You interrupt the boot loader and are able to modify the command line
for the booted kernel.

The boot loader loads the kernel and verifies the kernel's signature.
Good, the kernel hasn't been tampered with.  The kernel starts running.

You've plugged in a USB drive to the device, and specified a partition
containing a root filesystem that you control to the kernel.  The
validated kernel finds the USB drive, and mounts it, and executes
your own binaries on the USB drive.

You run a shell on the console.  You now have control of the system,
and can mount the real rootfs, inspect it, and work out what it does,
etc.

At this point, what use was all the validation that the secure boot
has done?  Absolutely useless.

If you can change the command line arguments given to the kernel, you
have no security, no matter how much you verify signatures.  It's
the illusion of security, nothing more, nothing less.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC 0/3] extend kexec_file_load system call

[Russell King - ARM Linux]

On Wed, Jul 13, 2016 at 05:55:33PM +1000, Stewart Smith wrote:
> Russell King - ARM Linux <li...@armlinux.org.uk> writes:
> > On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote:
> >> Russell King - ARM Linux <li...@armlinux.org.uk> writes:
> >> > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote:
> >> >> I'm not an expert on DTB, so I can't provide an example of code
> >> >> execution, but you have already mentioned the /chosen/linux,stdout-path
> >> >> property. If an attacker redirects the bootloader to an insecure
> >> >> console, they may get access to the system that would otherwise be
> >> >> impossible.
> >> >
> >> > I fail to see how kexec connects with the boot loader - the DTB image
> >> > that's being talked about is one which is passed from the currently
> >> > running kernel to the to-be-kexec'd kernel.  For ARM (and I suspect
> >> > also ARM64) that's a direct call chain which doesn't involve any
> >> > boot loader or firmware, and certainly none that would involve the
> >> > passed DTB image.
> >> 
> >> For OpenPOWER machines, kexec is the bootloader. Our bootloader is a
> >> linux kernel and initramfs with a UI (petitboot) - this means we never
> >> have to write a device driver twice: write a kernel one and you're done
> >> (for booting from the device and using it in your OS).
> >
> > I think you misunderstood my point.
> >
> > On ARM, we do not go:
> >
> > kernel (kexec'd from) -> boot loader -> kernel (kexec'd to)
> >
> > but we go:
> >
> > kernel (kexec'd from) -> kernel (kexec'd to)
> >
> > There's no intermediate step involving any bootloader.
> >
> > Hence, my point is that the dtb loaded by kexec is _only_ used by the
> > kernel which is being kexec'd to, not by the bootloader, nor indeed
> > the kernel which it is loaded into.
> >
> > Moreover, if you read the bit that I quoted (which is what I was
> > replying to), you'll notice that it is talking about the DTB loaded
> > by kexec somehow causing the _bootloader_ to be redirected to an
> > alternative console.  This point is wholely false on ARM.
> 
> Ahh.. I missed the bootloader bit there.
> 
> In which case, we're the same on OpenPOWER, there is no intermediate
> bootloader - in our case we have linux (with kexec) taking on what uboot
> or grub is typically used for on other platforms.

Indeed - maybe Eric knows better, but I can't see any situation where
the dtb we load via kexec should ever affect "the bootloader", unless
the "kernel" that's being loaded into kexec is "the bootloader".

Now, going back to the more fundamental issue raised in my first reply,
about the kernel command line.

On x86, I can see that it _is_ possible for userspace to specify a
command line, and the kernel loading the image provides the command
line to the to-be-kexeced kernel with very little checking.  So, if
your kernel is signed, what stops the "insecure userspace" loading
a signed kernel but giving it an insecure rootfs and/or console?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC 0/3] extend kexec_file_load system call

[Russell King - ARM Linux]

On Wed, Jul 13, 2016 at 09:47:56AM +0200, Ard Biesheuvel wrote:
> On 13 July 2016 at 09:36, Russell King - ARM Linux
> <li...@armlinux.org.uk> wrote:
> > On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote:
> >> Russell King - ARM Linux <li...@armlinux.org.uk> writes:
> >> > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote:
> >> >> I'm not an expert on DTB, so I can't provide an example of code
> >> >> execution, but you have already mentioned the /chosen/linux,stdout-path
> >> >> property. If an attacker redirects the bootloader to an insecure
> >> >> console, they may get access to the system that would otherwise be
> >> >> impossible.
> >> >
> >> > I fail to see how kexec connects with the boot loader - the DTB image
> >> > that's being talked about is one which is passed from the currently
> >> > running kernel to the to-be-kexec'd kernel.  For ARM (and I suspect
> >> > also ARM64) that's a direct call chain which doesn't involve any
> >> > boot loader or firmware, and certainly none that would involve the
> >> > passed DTB image.
> >>
> >> For OpenPOWER machines, kexec is the bootloader. Our bootloader is a
> >> linux kernel and initramfs with a UI (petitboot) - this means we never
> >> have to write a device driver twice: write a kernel one and you're done
> >> (for booting from the device and using it in your OS).
> >
> > I think you misunderstood my point.
> >
> > On ARM, we do not go:
> >
> > kernel (kexec'd from) -> boot loader -> kernel (kexec'd to)
> >
> > but we go:
> >
> > kernel (kexec'd from) -> kernel (kexec'd to)
> >
> > There's no intermediate step involving any bootloader.
> >
> > Hence, my point is that the dtb loaded by kexec is _only_ used by the
> > kernel which is being kexec'd to, not by the bootloader, nor indeed
> > the kernel which it is loaded into.
> >
> > Moreover, if you read the bit that I quoted (which is what I was
> > replying to), you'll notice that it is talking about the DTB loaded
> > by kexec somehow causing the _bootloader_ to be redirected to an
> > alternative console.  This point is wholely false on ARM.
> >
> 
> The particular example may not apply, but the argument that the DTB
> -as a description of the hardware topology- needs to be signed if the
> kernel is also signed is valid. We do the same in the UEFI stub, i.e.,
> it normally takes a dtb= argument to allow the DTB to be overridden,
> but this feature is disabled when Secure Boot is in effect. By the
> same reasoning, if any kind of kexec kernel image validation is in
> effect, we should either validate the DTB image as well, or disallow
> external DTBs and only perform kexec with the kernel's current DTB
> (the blob it was booted with, not the unflattened data structure)

*Sigh*  yes, I know full well, which is why I said what I said in my
_first_ reply:

"However, your point is valid as an attacker can redirect the console
 and/or mounted root on the to-be-kexec'd kernel if they can modify
 the DTB - and there's a whole host of subtle ways to do that, not
 necessarily just modification of the kernel command line."

and I went on to raise a valid point about the necessity to do that
for crashdump, which has been _completely_ ignored.

So, I just stopped reading your reply after the first three lines,
because we are in fact in agreement... but thanks for trying to waste
my time.

Please, keep with the overall discussion, and stop replying to a single
email as a whole point in isolation to every other email in the thread.
And stop bikeshedding, by picking up on the easy stuff but ignoring the
more fundamental points, like the crashdump issue I mentioned in my
first reply and now this reply.

Thanks.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC 0/3] extend kexec_file_load system call

[Russell King - ARM Linux]

On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote:
> Russell King - ARM Linux <li...@armlinux.org.uk> writes:
> > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote:
> >> I'm not an expert on DTB, so I can't provide an example of code
> >> execution, but you have already mentioned the /chosen/linux,stdout-path
> >> property. If an attacker redirects the bootloader to an insecure
> >> console, they may get access to the system that would otherwise be
> >> impossible.
> >
> > I fail to see how kexec connects with the boot loader - the DTB image
> > that's being talked about is one which is passed from the currently
> > running kernel to the to-be-kexec'd kernel.  For ARM (and I suspect
> > also ARM64) that's a direct call chain which doesn't involve any
> > boot loader or firmware, and certainly none that would involve the
> > passed DTB image.
> 
> For OpenPOWER machines, kexec is the bootloader. Our bootloader is a
> linux kernel and initramfs with a UI (petitboot) - this means we never
> have to write a device driver twice: write a kernel one and you're done
> (for booting from the device and using it in your OS).

I think you misunderstood my point.

On ARM, we do not go:

kernel (kexec'd from) -> boot loader -> kernel (kexec'd to)

but we go:

kernel (kexec'd from) -> kernel (kexec'd to)

There's no intermediate step involving any bootloader.

Hence, my point is that the dtb loaded by kexec is _only_ used by the
kernel which is being kexec'd to, not by the bootloader, nor indeed
the kernel which it is loaded into.

Moreover, if you read the bit that I quoted (which is what I was
replying to), you'll notice that it is talking about the DTB loaded
by kexec somehow causing the _bootloader_ to be redirected to an
alternative console.  This point is wholely false on ARM.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [RFC 0/3] extend kexec_file_load system call

[Russell King - ARM Linux]

On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote:
> I'm not an expert on DTB, so I can't provide an example of code
> execution, but you have already mentioned the /chosen/linux,stdout-path
> property. If an attacker redirects the bootloader to an insecure
> console, they may get access to the system that would otherwise be
> impossible.

I fail to see how kexec connects with the boot loader - the DTB image
that's being talked about is one which is passed from the currently
running kernel to the to-be-kexec'd kernel.  For ARM (and I suspect
also ARM64) that's a direct call chain which doesn't involve any
boot loader or firmware, and certainly none that would involve the
passed DTB image.

However, your point is valid as an attacker can redirect the console
and/or mounted root on the to-be-kexec'd kernel if they can modify
the DTB - and there's a whole host of subtle ways to do that, not
necessarily just modification of the kernel command line.

> In general, tampering with the hardware inventory of a machine opens up
> a security hole, and one must be very cautious which modifications are
> allowed. You're giving this power to an (unsigned, hence untrusted)
> userspace application; Eric argues that only the kernel should have
> this power.

Given that, how does crashdump work in this scenario?

crashdump works by adding an elfcorehdr=address argument to the
crash-booted kernel's command line.  If you can add to the kernel
command line, you can redirect the console and do all sorts of
other stuff like specifying a different filesystem to mount, etc.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 2/2] arm: use zImage size from header

[Russell King]

We do not support zImage with an appended DTB as we need to supply our
own DTB to the kernel, and an appended DTB will override any that we
try to supply.  To ensure that we do not load an appended DTB, clamp
the kernel size to the size specified in the zImage header.

Signed-off-by: Russell King <r...@armlinux.org.uk>
---
 kexec/arch/arm/kexec-zImage-arm.c | 36 
 1 file changed, 36 insertions(+)

diff --git a/kexec/arch/arm/kexec-zImage-arm.c 
b/kexec/arch/arm/kexec-zImage-arm.c
index c8b90f96..7f02b931 100644
--- a/kexec/arch/arm/kexec-zImage-arm.c
+++ b/kexec/arch/arm/kexec-zImage-arm.c
@@ -28,6 +28,14 @@ off_t initrd_base = 0, initrd_size = 0;
 unsigned int kexec_arm_image_size = 0;
 unsigned long long user_page_offset = (-1ULL);
 
+struct zimage_header {
+   uint32_t instr[9];
+   uint32_t magic;
+#define ZIMAGE_MAGIC cpu_to_le32(0x016f2818)
+   uint32_t start;
+   uint32_t end;
+};
+
 struct android_image {
char magic[8];
uint32_t kernel_size;
@@ -435,6 +443,34 @@ int zImage_arm_load(int argc, char **argv, const char 
*buf, off_t len,
if (dtb_file)
dtb_buf = slurp_file(dtb_file, _length);
 
+   if (len > 0x34) {
+   const struct zimage_header *hdr;
+   off_t size;
+
+   hdr = (const struct zimage_header *)buf;
+
+   dbgprintf("zImage header: 0x%08x 0x%08x 0x%08x\n",
+ hdr->magic, hdr->start, hdr->end);
+
+   if (hdr->magic == ZIMAGE_MAGIC) {
+   size = le32_to_cpu(hdr->end) - le32_to_cpu(hdr->start);
+
+   dbgprintf("zImage size 0x%llx, file size 0x%llx\n",
+ (unsigned long long)size,
+ (unsigned long long)len);
+
+   if (size > len) {
+   fprintf(stderr,
+   "zImage is truncated - file 0x%llx vs 
header 0x%llx\n",
+   (unsigned long long)len,
+   (unsigned long long)size);
+   return -1;
+   }
+   if (size < len)
+   len = size;
+   }
+   }
+
/* Handle android images, 2048 is the minimum page size */
if (len > 2048 && !strncmp(buf, "ANDROID!", 8)) {
const struct android_image *aimg = (const void *)buf;
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec failures with DEBUG_RODATA

[Russell King - ARM Linux]

On Wed, Jun 15, 2016 at 11:42:28PM +0100, Russell King - ARM Linux wrote:
> The boot environment must be setup such that there is room for the
> uncompressed image (aligned currently to 256 bytes) followed by the
> size of the compressed image, with any appended DTBs included.
> Anything which is located below that is likely to get trampled by
> the decompressor.

There's a question that's been lingering, which hasn't been brought up
by anyone yet: should we even support zImage files with an appended
DTB for kexec?

When kexec is operating in DTB mode, it will provide the DTB to the
kernel from the host environment, possibly with some modifications (eg,
to change the command line arguments.)  Since an appended DTB would
override the kexec-provided DTB, this would wipe out those changes,
some of which are necessary for things like crashdump to work.

So, I'm thinking that kexec should not support a zImage with appended
DTB - in fact, I think it should truncate the zImage to be loaded, and
ensure that the word following the zImage does not contain a DTB magic
number, in case the zImage has been built with CONFIG_ARM_APPENDED_DTB
enabled.

Thoughts?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec failures with DEBUG_RODATA

[Russell King - ARM Linux]

On Wed, Jun 15, 2016 at 10:13:59PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 14, 2016 at 11:05:23AM -0700, Kees Cook wrote:
> > I'm much less familiar with the ARM decompression stub, but is there a
> > boot image header (like x86 has)? If not, perhaps we can invent one,
> > and it can carry all the details needed for a bootloader to do the
> > right things.
> 
> With a bit of tinkering around, I now have this:
> 
>  <.data>:
>0:   e1a0nop ; (mov r0, r0)
>4:   e1a0nop ; (mov r0, r0)
>8:   e1a0nop ; (mov r0, r0)
>c:   e1a0nop ; (mov r0, r0)
>   10:   e1a0nop ; (mov r0, r0)
>   14:   e1a0nop ; (mov r0, r0)
>   18:   e1a0nop ; (mov r0, r0)
>   1c:   e1a0nop ; (mov r0, r0)
>   20:   ea0fb   0x64
> 
> Then follows the existing "header" which we've had there for years:
> 
>   24:   016f2818  ; LE magic number
>   28:     ; LE zImage start address (always zero now)
>   2c:   00431fe0  ; LE zImage _edata
>   30:   04030201  ; endian flag
> 
> And now comes the new header:
> 
>   34:   016f2818  ; LE magic number
>   38:   0001  ; LE version number (v1)
>   3c:   01287000  ; LE total space required for decompressor
>   40:   00e54000  ; LE uncompressed image size
> 
> Up to 64 bytes available here for future expansion, currently filled
> with zeros.
> ...
> 
> Remainder of the zImage code:
>   64:   e10f9000mrs r9, CPSR

Looking at this again, this can't work for another _two_ reasons:

1. Thumb2 kernels - we rely on a relative address to jump to for the
   remainder of the zImage code, using an "adr" instruction.  The offset
   needs to be known at assembly time, but with my approach of moving
   the header into the linker script, this is no longer the case.

2. EFI images need the header offset at 0x3c, which gets in the way of
   us appending to our existing header.

So... I don't think we can solve it this way, and I'm all out of ideas
how to solve this in a sane manner - I'm currently of the opinion that
it _isn't_ solvable given where we are without defining a new format
for a zImage, which is really quite depressing.

I think people are just going to have to get used to using --image-size
to kexec on ARM to work around this problem.  So, let's document it
in kexec's --help - though this could do with something better, but I
fear it'll turn into a multi-line description of the option:

 kexec/arch/arm/kexec-zImage-arm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kexec/arch/arm/kexec-zImage-arm.c 
b/kexec/arch/arm/kexec-zImage-arm.c
index 9400d1f4..45c587c2 100644
--- a/kexec/arch/arm/kexec-zImage-arm.c
+++ b/kexec/arch/arm/kexec-zImage-arm.c
@@ -122,6 +122,8 @@ void zImage_arm_usage(void)
" --initrd=FILE Use FILE as the kernel's initial 
ramdisk.\n"
" --ramdisk=FILEUse FILE as the kernel's initial 
ramdisk.\n"
" --dtb=FILEUse FILE as the fdt blob.\n"
+   " --image-size=IMAGE_SIZE\n"
+   "   Reserve IMAGE_SIZE between kernel 
and initrd.\n"
" --atags   Use ATAGs instead of device-tree.\n"
" --page-offset=PAGE_OFFSET\n"
"   Set PAGE_OFFSET of crash dump 
vmcore\n"


-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 2/2] arm: fix kernel image size

[Russell King - ARM Linux]

On Wed, Jun 22, 2016 at 12:36:16AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <li...@armlinux.org.uk> [160621 14:54]:
> > So that's 20.7MB, and the zImage was 3.6MB.  You're getting an
> > expansion ratio of 5.7x.
> > 
> > To fix that, we'd need to up it to 7x, but the problem with upping
> > it in this way is that it increases the requirements for the
> > crashdump region too.  We can play with this number, but there will
> > always be cases where it doesn't work - either because the ratio is
> > too big or too small.
> 
> OK
> 
> > By way of illustration, "zImage size + MAX_RODATA_SZ + 4x zImage size"
> > doesn't even work for this case, since you need about 25MB.  Your
> > calculation comes out at 22MB, which is 3MB short.  Not only that, but
> > it introduces (from what I can see) an irrelevant fudge factor of
> > "MAX_RODATA_SZ" which has no basis in what's really going on here, and
> > I'm left wondering what "MAX_RODATA_SZ" is actually referring to.
> 
> Well I thinking the section alignment split might give us some
> known size for rodata, but looking at it more it's only with
> DEBUG_ALIGN_RODATA. If we can't make any assumptions about the
> size of the rodata, then no point adding it.

I think you're just getting completely confused about what the problem
is, due to the naming of the config option.

It's got nothing to do with the size of the read-only data.  Really.

When CONFIG_DEBUG_RODATA is enabled, we align the text, read-only data,
data, and so on to 1MB boundaries so that we can change the permissions
of the sections to enforce the properties of the various ELF segments.
This padding massively inflates the size of the run-time kernel image,
and can result in megabytes of wastage (if we're as little as one byte
into 1MB, we have to round up to the next megabyte.)

The padding, being a string of zeros, is very compressable, and this
increases the compression ratio.

The BSS is not included in the compressed image, but needs to be taken
account of when avoiding overwriting the DTB.

> How about we check the size of RAM available, and if there is plenty
> of RAM we use a safe compression ratio of 8. If RAM is a problem,
> we could make the compression ratio smaller and warn about it. And
> we could also allow passing the compression ratio to kexec as an
> option.

You do know that you can already pass the "size" of the kernel to be
reserved to kexec.  --image-size.  It's not documented in --help, but
it is there (which is another annoying thing about ARM kexec...)

> I forgot if we still have some 128MB limits too..

We do.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 2/2] arm: fix kernel image size

[Russell King - ARM Linux]

On Tue, Jun 21, 2016 at 09:55:25AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <li...@armlinux.org.uk> [160621 08:46]:
> > On Tue, Jun 21, 2016 at 03:57:20AM -0700, Tony Lindgren wrote:
> > > 
> > > Maybe zImage size + MAX_RODATA_SZ + 4x zImage size?
> > > 
> > > Then the MAX_RODATA_SZ could be 2 or 4 MB or whatever we
> > > think is sufficient to kick the can until we have a better
> > > solution.
> > 
> > Maybe if you give some details about your failing case - you omitted any
> > details about the uncompressed image size...
> 
> Looks like we currently have this:
> 
> Memory: 2033088K/2095100K available (7376K kernel code, 784K rwdata,
> 2312K rodata, 1024K init, 8117K bss, 45628K reserved,
> 16384K cma-reserved, 1292284K highmem)
> Virtual kernel memory layout:
> vector  : 0x - 0x1000   (   4 kB)
> fixmap  : 0xffc0 - 0xfff0   (3072 kB)
> vmalloc : 0xf080 - 0xff80   ( 240 MB)
> lowmem  : 0xc000 - 0xf000   ( 768 MB)
> pkmap   : 0xbfe0 - 0xc000   (   2 MB)
> modules : 0xbf00 - 0xbfe0   (  14 MB)
>   .text : 0xc0008000 - 0xc0a762a4   (10681 kB)
>   .init : 0xc0b0 - 0xc0c0   (1024 kB)
>   .data : 0xc0c0 - 0xc0cc411c   ( 785 kB)
>.bss : 0xc0cc6000 - 0xc14b37f8   (8118 kB)

So that's 20.7MB, and the zImage was 3.6MB.  You're getting an
expansion ratio of 5.7x.

To fix that, we'd need to up it to 7x, but the problem with upping
it in this way is that it increases the requirements for the
crashdump region too.  We can play with this number, but there will
always be cases where it doesn't work - either because the ratio is
too big or too small.

By way of illustration, "zImage size + MAX_RODATA_SZ + 4x zImage size"
doesn't even work for this case, since you need about 25MB.  Your
calculation comes out at 22MB, which is 3MB short.  Not only that, but
it introduces (from what I can see) an irrelevant fudge factor of
"MAX_RODATA_SZ" which has no basis in what's really going on here, and
I'm left wondering what "MAX_RODATA_SZ" is actually referring to.

So... I'm of the opinion that we shouldn't play with it - but instead
try to come up with a solution which *doesn't* involve teaching kexec
a whole load of internals about how the ARM kernel booting happens.

What's more worrying to me at the moment, though, is that the kexec code
only tries to find memory for the actual "kernel" size, not the actual
space required to decompress the kernel.  It could find a chunk of
memory large enough to fit the kernel image to be loaded, but is not big
enough to allow its decompression.  kexec is really quite a mess on
ARM. :(

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 2/2] arm: fix kernel image size

[Russell King - ARM Linux]

On Tue, Jun 21, 2016 at 03:57:20AM -0700, Tony Lindgren wrote:
> * Tony Lindgren <t...@atomide.com> [160621 03:41]:
> > * Russell King - ARM Linux <li...@armlinux.org.uk> [160621 02:50]:
> > > 
> > > There isn't really an answer which will always work for this problem,
> > > as I've already detailed in a previous thread discussing the issue.
> > > Adding a zImage header don't fix the problem.
> > 
> > Well how about we change both comments and code to use a value
> > that works?
> 
> Maybe zImage size + MAX_RODATA_SZ + 4x zImage size?
> 
> Then the MAX_RODATA_SZ could be 2 or 4 MB or whatever we
> think is sufficient to kick the can until we have a better
> solution.

Maybe if you give some details about your failing case - you omitted any
details about the uncompressed image size...

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec failures with DEBUG_RODATA

[Russell King - ARM Linux]

On Tue, Jun 21, 2016 at 05:18:49PM +0530, Pratyush Anand wrote:
> On 16/06/2016:12:13:03 AM, Russell King - ARM Linux wrote:
> > I should point out that this method should work for a zImage without
> > an appended DTB, and we have no way to update this header block for
> > the appended DTB case.
> 
> Well, I might be missing with my limited knowledge. So, just to clarify, 
> zImage
> is "compressed image + uncompressor". In some cases it might have "+DTB".
> So, zImage should be located atleast "aligned uncompressed size" above "kernel
> base" and, initrd should be placed at "kernel base" +  "aligned uncompressed
> size" + "compressed image size" + "uncompressor size" + DTB(if any).
> 
> However, I am unable to understand that why can't we have a flag in zImage
> header block, which tells that whether a DTB has been appended in the zImage 
> or
> not?

cat zImage foo.dtb > newImage

obviously doesn't result in the header block inside zImage being modified.
The only way around that is to have a tool which concatenates the two
and updates the header.  At that point, it's no longer simply a
concatenation.

> > So, an alternative standpoint is that we supply only the uncompressed
> > image size.  Then, the boot environment needs to understand that they
> > must allow for the compressed image and any appended DTB on top of that
> > (which it would see as one - the size of the combined image.)
> 
> So, why not we can have all three information in header ie. "uncompressed 
> image
> size", "compressed image size" and "DTB size" if appended flag is set.

How big is the DTB size?  Without a tool to update the header, there's
no way to really know.

> > However, while that may sound like a good idea, we're falling into the
> > same trap that we've fallen into at the beginning of this thread: the
> > boot environment has to understand how the decompressor currently works,
> > and if we were to change that, this we're back to the calculation which
> > the boot environment is using not matching reality.
> 
> Currently we are discussing between 4 times to 11 times. So, if we know
> *atleast* "uncompressed image size" then this heuristic variation can be
> minimized a lot. If we do not provide header, then may be we can provide 
> library
> to the kexec-tools which will enable us to know the length of "uncompressed
> image" when "compressed image" is provided as input.

If we provide the uncompressed size, then we know how big the uncompressed
image will be.  That much is fine, but there's more than that.

What is the padding applied to the uncompressed size?  Where does the
compressed image self-relocate to?  Where does the compressed image
relocate the DTB to?  What is the spacing between the DTB and the
compressed image?

All those are knowledge which is internal to the decompressor code.
If we supply, say, the padded uncompressed size, then we can work
around not knowing the padding in kexec.  However, we still need to
know the other details - so we still end up needing to code into
kexec (or other boot environment) a load of details specific to the
current decompressor implementation.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 2/2] arm: fix kernel image size

[Russell King - ARM Linux]

On Tue, Jun 21, 2016 at 12:43:21AM -0700, Tony Lindgren wrote:
> Hi,
> 
> * Russell King <r...@armlinux.org.uk> [160617 12:52]:
> > If we want to assume that the compressed image will expand by a maximum
> > of 4x, we actually need to reserve 5x the space, since we need to keep
> > a copy of the compessed image around while decompressing.
> 
> Looks like 5x is not enough with omap2plus_defconfig at least..
> This one needs to be set to 6x for that. Maybe we should just make
> it go all the way to 11 :)

That's not really what this commit is about - it's about making the
code consistent with the comments in the file.  I could have instead
changed the comment saying "4x" to "3x" instead.

There isn't really an answer which will always work for this problem,
as I've already detailed in a previous thread discussing the issue.
Adding a zImage header don't fix the problem.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 0/2] Simple fix to the ARM kexec tools implementation

[Russell King - ARM Linux]

On Tue, Jun 21, 2016 at 11:41:28AM +0530, Pratyush Anand wrote:
> Yes, so until we have proper header for zImage, these patches looks
> fine to me.

If you read my last email in the "kexec failures with DEBUG_RODATA"
thread, you'll see that I'm unhappy with this idea, because adding a
"proper header" still results in some kind of assumption about how
the zImage decompressor works being needed by the boot environment.

> For both of the patches:
> 
> Reviewed-by: Pratyush Anand 

Thanks.

Simon, do you need me to resend with the r-b tag, or will you pick
these two up and the documentation fix patch you asked for?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 1/2] arm: take account of TEXT_OFFSET for subsequent images

[Russell King]

The ARM kexec code was not taking account of the 32k text offset when
applying the size(s) of the kernel image.  We need to take account of
this so when we decide to place the initrd at 4x the compressed image
length, it is appropriately placed.

Signed-off-by: Russell King <r...@armlinux.org.uk>
---
 kexec/arch/arm/kexec-zImage-arm.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/kexec/arch/arm/kexec-zImage-arm.c 
b/kexec/arch/arm/kexec-zImage-arm.c
index aab0c861..297b7fd8 100644
--- a/kexec/arch/arm/kexec-zImage-arm.c
+++ b/kexec/arch/arm/kexec-zImage-arm.c
@@ -340,7 +340,7 @@ static int setup_dtb_prop(char **bufp, off_t *sizep, int 
parentoffset,
 int zImage_arm_load(int argc, char **argv, const char *buf, off_t len,
struct kexec_info *info)
 {
-   unsigned long base;
+   unsigned long base, kernel_base;
unsigned int atag_offset = 0x1000; /* 4k offset from memory start */
unsigned int extra_size = 0x8000; /* TEXT_OFFSET */
const char *command_line;
@@ -517,15 +517,17 @@ int zImage_arm_load(int argc, char **argv, const char 
*buf, off_t len,
if (base == ULONG_MAX)
return -1;
 
+   kernel_base = base + extra_size;
+
if (kexec_arm_image_size) {
/* If the image size was passed as command line argument,
 * use that value for determining the address for initrd,
 * atags and dtb images. page-align the given length.*/
-   initrd_base = base + _ALIGN(kexec_arm_image_size, 
getpagesize());
+   initrd_base = kernel_base + _ALIGN(kexec_arm_image_size, 
getpagesize());
} else {
/* Otherwise, assume the maximum kernel compression ratio
 * is 4, and just to be safe, place ramdisk after that */
-   initrd_base = base + _ALIGN(len * 4, getpagesize());
+   initrd_base = kernel_base + _ALIGN(len * 4, getpagesize());
}
 
if (use_atags) {
@@ -617,9 +619,9 @@ int zImage_arm_load(int argc, char **argv, const char *buf, 
off_t len,
dtb_offset, dtb_length);
}
 
-   add_segment(info, buf, len, base + extra_size, len);
+   add_segment(info, buf, len, kernel_base, len);
 
-   info->entry = (void*)base + extra_size;
+   info->entry = (void*)kernel_base;
 
return 0;
 }
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 2/2] arm: fix kernel image size

[Russell King]

If we want to assume that the compressed image will expand by a maximum
of 4x, we actually need to reserve 5x the space, since we need to keep
a copy of the compessed image around while decompressing.

Signed-off-by: Russell King <r...@armlinux.org.uk>
---
 kexec/arch/arm/kexec-zImage-arm.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/kexec/arch/arm/kexec-zImage-arm.c 
b/kexec/arch/arm/kexec-zImage-arm.c
index 297b7fd8..9400d1f4 100644
--- a/kexec/arch/arm/kexec-zImage-arm.c
+++ b/kexec/arch/arm/kexec-zImage-arm.c
@@ -526,8 +526,10 @@ int zImage_arm_load(int argc, char **argv, const char 
*buf, off_t len,
initrd_base = kernel_base + _ALIGN(kexec_arm_image_size, 
getpagesize());
} else {
/* Otherwise, assume the maximum kernel compression ratio
-* is 4, and just to be safe, place ramdisk after that */
-   initrd_base = kernel_base + _ALIGN(len * 4, getpagesize());
+* is 4, and just to be safe, place ramdisk after that.
+* Note that we must include space for the compressed
+* image here as well. */
+   initrd_base = kernel_base + _ALIGN(len * 5, getpagesize());
}
 
if (use_atags) {
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 0/2] Simple fix to the ARM kexec tools implementation

[Russell King - ARM Linux]

This is the "simple" fix for the ARM kexec tools code, which makes
the code actually do what the comments describe.

There are two problems:

1. When placing the initrd, we do not take account of the 32k offset
   that is required for the kernel image.

2. The code claims to allow the zImage decompressor to expand by a
   factor of 4, but only allows space for a factor of 3, since the
   decompressor itself has to fit in this memory space as well.

Changing the code to follow the comments allows Keystone II to kexec
with DEBUG_RODATA enabled, at least with the kernel I've been testing
with.

This is a stop-gap solution until a better solution can be implemented.

 kexec/arch/arm/kexec-zImage-arm.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec failures with DEBUG_RODATA

[Russell King - ARM Linux]

On Wed, Jun 15, 2016 at 03:54:38PM -0700, Kees Cook wrote:
> On Wed, Jun 15, 2016 at 3:42 PM, Russell King - ARM Linux
> <li...@armlinux.org.uk> wrote:
> > In fact, the apparent confusion over this reinforces my belief that we
> > should _not_ give the size of the uncompressed image at all.
> >
> > The boot environment must be setup such that there is room for the
> > uncompressed image (aligned currently to 256 bytes) followed by the
> > size of the compressed image, with any appended DTBs included.
> > Anything which is located below that is likely to get trampled by
> > the decompressor.
> 
> Okay, sounds reasonable to me. :)

I should point out that this method should work for a zImage without
an appended DTB, and we have no way to update this header block for
the appended DTB case.

So, an alternative standpoint is that we supply only the uncompressed
image size.  Then, the boot environment needs to understand that they
must allow for the compressed image and any appended DTB on top of that
(which it would see as one - the size of the combined image.)

However, while that may sound like a good idea, we're falling into the
same trap that we've fallen into at the beginning of this thread: the
boot environment has to understand how the decompressor currently works,
and if we were to change that, this we're back to the calculation which
the boot environment is using not matching reality.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec failures with DEBUG_RODATA

[Russell King - ARM Linux]

On Tue, Jun 14, 2016 at 11:05:23AM -0700, Kees Cook wrote:
> I'm much less familiar with the ARM decompression stub, but is there a
> boot image header (like x86 has)? If not, perhaps we can invent one,
> and it can carry all the details needed for a bootloader to do the
> right things.

With a bit of tinkering around, I now have this:

 <.data>:
   0:   e1a0nop ; (mov r0, r0)
   4:   e1a0nop ; (mov r0, r0)
   8:   e1a0nop ; (mov r0, r0)
   c:   e1a0nop ; (mov r0, r0)
  10:   e1a0nop ; (mov r0, r0)
  14:   e1a0nop ; (mov r0, r0)
  18:   e1a0nop ; (mov r0, r0)
  1c:   e1a0nop ; (mov r0, r0)
  20:   ea0fb   0x64

Then follows the existing "header" which we've had there for years:

  24:   016f2818; LE magic number
  28:   ; LE zImage start address (always zero now)
  2c:   00431fe0; LE zImage _edata
  30:   04030201; endian flag

And now comes the new header:

  34:   016f2818; LE magic number
  38:   0001; LE version number (v1)
  3c:   01287000; LE total space required for decompressor
  40:   00e54000; LE uncompressed image size

Up to 64 bytes available here for future expansion, currently filled
with zeros.
...

Remainder of the zImage code:
  64:   e10f9000mrs r9, CPSR

I'm rather on the fence whether we need to give the uncompressed image
size - the important thing is the size of memory that's required for
the decompressor to run, which is sizeof(uncompressed kernel) rounded
up to 256 bytes, and the relocated decompressor image size.

The "total space required for decompressor" is slightly cheating at the
figure - I'm including the uncompressed image rounded up and the entire
compressed image in that size, so it's a safe over-estimate.

I'm not sure there's a need to provide the uncompressed image size, the
boot environment shouldn't have a reason to know that, so I'm tempted to
omit it.

We could dispense with the endian conversions, and push the responsibility
for interpreting that onto the reader of this data: we have the endian
flag in the existing header block, so the boot environment can work out
the endianness of the image and apply fixups as appropriate.

Why generate this in the linker script?  We need the size of the zImage
here, which is only known to the linker.

diff --git a/arch/arm/boot/compressed/Makefile 
b/arch/arm/boot/compressed/Makefile
index d50430c40045..1d5467e05250 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -119,6 +119,10 @@ asflags-y := -DZIMAGE
 KBSS_SZ = $(shell $(CROSS_COMPILE)size $(obj)/../../../../vmlinux | \
awk 'END{print $$3}')
 LDFLAGS_vmlinux = --defsym _kernel_bss_size=$(KBSS_SZ)
+
+KERNEL_IMAGE_SIZE = $(shell stat -c '%s' $(obj)/../Image)
+LDFLAGS_vmlinux += --defsym _kernel_image_size=$(KERNEL_IMAGE_SIZE)
+
 # Supply ZRELADDR to the decompressor via a linker symbol.
 ifneq ($(CONFIG_AUTO_ZRELADDR),y)
 LDFLAGS_vmlinux += --defsym zreladdr=$(ZRELADDR)
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index e2e0dcb42ca2..395c60dcc4f7 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -131,11 +131,7 @@ start:
  THUMB(badrr12, 1f )
  THUMB(bx  r12 )
 
-   .word   _magic_sig  @ Magic numbers to help the loader
-   .word   _magic_start@ absolute load/run zImage address
-   .word   _magic_end  @ zImage end address
-   .word   0x04030201  @ endianness flag
-
+   .section ".start2", #alloc, #execinstr
  THUMB(.thumb  )
 1: __EFI_HEADER
 
diff --git a/arch/arm/boot/compressed/vmlinux.lds.S 
b/arch/arm/boot/compressed/vmlinux.lds.S
index 81c493156ce8..77267724ec8a 100644
--- a/arch/arm/boot/compressed/vmlinux.lds.S
+++ b/arch/arm/boot/compressed/vmlinux.lds.S
@@ -37,6 +37,19 @@ SECTIONS
   .text : {
 _start = .;
 *(.start)
+_header = .;
+LONG(ZIMAGE_MAGIC(0x016f2818));/* Magic numbers to help the loader */
+LONG(ZIMAGE_MAGIC(_start));/* absolute load/run zImage 
address */
+LONG(ZIMAGE_MAGIC(_edata));/* zImage end address */
+LONG(0x04030201);  /* Endianness flag */
+LONG(ZIMAGE_MAGIC(0x016f2818));/* Further header indicator */
+LONG(ZIMAGE_MAGIC(1)); /* Version 1 */
+LONG(ZIMAGE_MAGIC(((_kernel_image_size + 255) & ~ 255) + \
+   _edata 

Re: kexec failures with DEBUG_RODATA

[Russell King - ARM Linux]

On Wed, Jun 15, 2016 at 01:25:08PM +0530, Pratyush Anand wrote:
> Sure, having a header information would be handy to do it. Other alternative
> could be that we define "HAVE_LIBZ" and then we can have something like
> kexec-Image-arm.c which handles plane Image.  We can also have something like
> get_zlib_decompressed_length() which can give us exact length we need for 
> kernel
> and then we can place initrd accordingly in zImage_arm_load().

I really don't want to do that.  There are things that the decompressor
does which make it easier to deal with the zImage than the Image.

> I see at least another issue clearly in ARM kernel code with 
> CONFIG_DEBUG_RODATA
> enabled.  When CONFIG_DEBUG_RODATA is enabled, we can not write text area.
> kexec_start_address has been defined in relocate_kernel.S as a text area.
> machine_kexec() writes at kexec_start_address with image->start. Similarly 
> there
> would be issues for overwriting of kexec_indirection_page, kexec_mach_type and
> kexec_boot_atags. If arm mmu mapping configures text pages as RO, then we 
> should
> see an abort as soon as we do these writes.

That's not a problem, because set_kernel_text_rw() is called immediately
prior to writing, which has the effect of allowing these writes.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

kexec failures with DEBUG_RODATA

[Russell King - ARM Linux]

Guys,

Having added Keystone2 support to kexec, and asking TI to validate
linux-next with mainline kexec-tools, I received two reports from
them.

The first was a report of success, but was kexecing a 4.4 kernel
from linux-next.

The second was a failure report, kexecing current linux-next from
linux-next on this platform.  However, my local tests (using my
4.7-rc3 derived kernel) showed there to be no problem.

Building my 4.7-rc3 derived kernel with TI's configuration they
were using with linux-next similarly failed.  So, it came down to
a configuration difference.

After trialling several configurations, it turns out that the
failure is, in part, caused by CONFIG_DEBUG_RODATA being enabled
on TI's kernel but not mine.  Why should this make any difference?

Well, CONFIG_DEBUG_RODATA has the side effect that the kernel
contains a lot of additional padding - we pad out to section size
(1MB) the ELF sections with differing attributes.  This should not
normally be a problem, except kexec contains this assumption:

/* Otherwise, assume the maximum kernel compression ratio
 * is 4, and just to be safe, place ramdisk after that */
initrd_base = base + _ALIGN(len * 4, getpagesize());

Now, first things first.  Don't get misled by the comment - it's
totally false.  That may be what's desired, but that is far from
what actually happens in reality.

"base" is _not_ the address of the start of the kernel image, but
is the base address of the start of the region that the kernel is
to be loaded into - remember that the kernel is normally loaded
32k higher than the start of memory.  This 32k offset is _not_
included in either "base" nor "len".  So, even if we did want to
assume that there was a maximum compression ratio of 4, the above
always calculates 32k short of that value.

The other invalid thing here is this whole "maximum kernel compression
ratio" assumption.  Consider this non-DEBUG_RODATA kernel image:

   textdata bss dec hex filename
6583513 2273816  215344 9072673  8a7021 ../build/ks2/vmlinux

This results in an image and zimage of:
-rwxrwxr-x 1 rmk rmk 8871936 Jun 14 18:02 ../build/ks2/arch/arm/boot/Image
-rwxrwxr-x 1 rmk rmk 4381592 Jun 14 18:02 ../build/ks2/arch/arm/boot/zImage

which is a ratio of about a 49%.  On entry to the decompressor, the
compressed image will be relocated above the expected resulting
kernel size.  So, let's say that it's relocated to 9MB.  This means
the zImage will occupy around 9MB-14MB above the start of memory.
Going by the 4x ratio, we place the other images at 16.7MB.  This
leaves around 2.7MB free.  So that's probably fine... but think
about this.  We assumed a ratio of 4x, but really we're in a rather
tight squeeze - we actually have only about 50% of the compressed
image size spare.

Now let's look at the DEBUG_RODATA case:

   textdata bss dec hex filename
6585305 2273952  215344 9074601  8a77a9 ../build/ks2/vmlinux

And the resulting sizes:
-rwxrwxr-x 1 rmk rmk 15024128 Jun 14 18:49 ../build/ks2/arch/arm/boot/Image
-rwxrwxr-x 1 rmk rmk  4399040 Jun 14 18:49 ../build/ks2/arch/arm/boot/zImage

That's a compression ratio of about 29%.  Still within the 4x limit,
but going through the same calculation above shows that we end up
totally overflowing the available space this time.

That's exactly the same kernel configuration except for
CONFIG_DEBUG_RODATA - enabling this has almost _doubled_ the
decompressed image size without affecting the compressed size.

We've known for some time that this ratio of 4x doesn't work - we
used to use the same assumption in the decompressor when self-
relocating, and we found that there are images which achieve a
better compression ratio and make this invalid.  Yet, the 4x thing
has persisted in kexec code... and buggily too.

Since the kernel now has CONFIG_DEBUG_RODATA by default, this means
that these kinds of ratio-based assumptions are even more invalid
than they have been.

Right now, a zImage doesn't advertise the size of its uncompressed
image, but I think with things like CONFIG_DEBUG_RODATA, we can no
longer make assumptions like we have done in the past, and we need
the zImage to provide this information so that the boot environment
can be setup sanely by boot loaders/kexec rather than relying on
broken heuristics like this.

Thoughts?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH] Remove "max" parameter comment

[Russell King]

Remove the "max" parameter in the documentation for mem_regions_add()

Signed-off-by: Russell King <r...@armlinux.org.uk>
---
 kexec/mem_regions.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kexec/mem_regions.c b/kexec/mem_regions.c
index b01a5c89..e61c0747 100644
--- a/kexec/mem_regions.c
+++ b/kexec/mem_regions.c
@@ -31,7 +31,6 @@ void mem_regions_sort(struct memory_ranges *ranges)
 /**
  * mem_regions_add() - add a memory region to a set of ranges
  * @ranges: ranges to add the memory region to
- * @max: maximum number of entries in memory region
  * @base: base address of memory region
  * @length: length of memory region in bytes
  * @type: type of memory region
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 24/32] arm: add support for platforms with boot memory aliases

[Russell King]

The kexec API deals with boot-view addresses, rather than normal system
view addresses.  This causes problems for platforms such as Keystone 2,
where the boot view is substantially different from the normal system
view.

This is because Keystone 2 boots from a memory alias in the lower 4GiB,
before switching to a high alias at 32GiB.

We handle this in a generic way by introducing boot alias resources in
/proc/iomem:

8000-dfff : System RAM (boot alias)
  9f80-9fff : Crash kernel (boot alias)
8-85fff : System RAM
  88000-800790e37 : Kernel code
  8007ec000-8008b856f : Kernel data
  81f80-81fff : Crash kernel

To allow kexec to load a kernel, we need to add the boot alias of RAM
to the memory ranges returned by get_memory_ranges().  Parse the
system RAM boot alias into the memory ranges.

Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kexec/arch/arm/iomem.h | 2 ++
 kexec/arch/arm/kexec-arm.c | 4 +++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/kexec/arch/arm/iomem.h b/kexec/arch/arm/iomem.h
index 81c593d..85f958e 100644
--- a/kexec/arch/arm/iomem.h
+++ b/kexec/arch/arm/iomem.h
@@ -2,6 +2,8 @@
 #define IOMEM_H
 
 #define SYSTEM_RAM "System RAM\n"
+#define SYSTEM_RAM_BOOT"System RAM (boot alias)\n"
 #define CRASH_KERNEL   "Crash kernel\n"
+#define CRASH_KERNEL_BOOT  "Crash kernel (boot alias)\n"
 
 #endif
diff --git a/kexec/arch/arm/kexec-arm.c b/kexec/arch/arm/kexec-arm.c
index eeb27b4..2194b7c 100644
--- a/kexec/arch/arm/kexec-arm.c
+++ b/kexec/arch/arm/kexec-arm.c
@@ -18,6 +18,7 @@
 #include "kexec-arm.h"
 #include 
 #include "../../fs2dt.h"
+#include "iomem.h"
 
 #define MAX_MEMORY_RANGES 64
 #define MAX_LINE 160
@@ -52,7 +53,8 @@ int get_memory_ranges(struct memory_range **range, int 
*ranges,
continue;
str = line + consumed;
 
-   if (memcmp(str, "System RAM\n", 11) == 0) {
+   if (memcmp(str, SYSTEM_RAM_BOOT, strlen(SYSTEM_RAM_BOOT)) == 0 
||
+   memcmp(str, SYSTEM_RAM, strlen(SYSTEM_RAM)) == 0) {
type = RANGE_RAM;
}
else if (memcmp(str, "reserved\n", 9) == 0) {
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 16/32] arm: fix ELF32/ELF64 check

[Russell King]

Rather than using ULONG_MAX to decide whether to use the ELF64 or ELF32
core dump format, use UINT32_MAX instead - we include stdint.h, so we
might as well use a constant which is meaningful for the limits of
the 32-bit ELF format.

Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index a390187..fcc4d42 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -369,8 +369,7 @@ int load_crashdump_segments(struct kexec_info *info, char 
*mod_cmdline)
if (last_ranges < 0)
last_ranges = 0;
 
-   if (crash_memory_ranges[last_ranges].end > ULONG_MAX) {
-
+   if (crash_memory_ranges[last_ranges].end > UINT32_MAX) {
/* for support LPAE enabled kernel*/
elf_info.class = ELFCLASS64;
 
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 09/32] kexec: phys_to_virt() must take unsigned long long

[Russell King]

crashdump-elf.c passes unsigned long long addresses into phys_to_virt()
so make phys_to_virt() accept such addresses without truncating them.
This is important for ARM LPAE systems.

Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kexec/arch/arm/phys_to_virt.c | 2 +-
 kexec/crashdump.h | 2 +-
 kexec/phys_to_virt.c  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/kexec/arch/arm/phys_to_virt.c b/kexec/arch/arm/phys_to_virt.c
index bcced52..c2fe2ea 100644
--- a/kexec/arch/arm/phys_to_virt.c
+++ b/kexec/arch/arm/phys_to_virt.c
@@ -14,7 +14,7 @@
  * 
http://lists.arm.linux.org.uk/lurker/message/20010723.185051.94ce743c.en.html
  */
 unsigned long
-phys_to_virt(struct crash_elf_info *elf_info, unsigned long paddr)
+phys_to_virt(struct crash_elf_info *elf_info, unsigned long long paddr)
 {
return paddr + elf_info->page_offset - phys_offset;
 }
diff --git a/kexec/crashdump.h b/kexec/crashdump.h
index 95f1f0c..96219a8 100644
--- a/kexec/crashdump.h
+++ b/kexec/crashdump.h
@@ -55,7 +55,7 @@ int crash_create_elf64_headers(struct kexec_info *info,
 unsigned long crash_architecture(struct crash_elf_info *elf_info);
 
 unsigned long phys_to_virt(struct crash_elf_info *elf_info,
-  unsigned long paddr);
+  unsigned long long paddr);
 
 unsigned long xen_architecture(struct crash_elf_info *elf_info);
 int xen_get_nr_phys_cpus(void);
diff --git a/kexec/phys_to_virt.c b/kexec/phys_to_virt.c
index 91b6d01..5e8c4e3 100644
--- a/kexec/phys_to_virt.c
+++ b/kexec/phys_to_virt.c
@@ -10,7 +10,7 @@
  * their own implementation.
  */
 unsigned long
-phys_to_virt(struct crash_elf_info *elf_info, unsigned long paddr)
+phys_to_virt(struct crash_elf_info *elf_info, unsigned long long paddr)
 {
return paddr + elf_info->page_offset;
 }
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 12/32] kexec: add helper to exlude a region from a set of memory ranges

[Russell King]

Add a helper to exclude a region from a set of memory ranges.

Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kexec/mem_regions.c | 71 +
 kexec/mem_regions.h |  4 +++
 2 files changed, 75 insertions(+)

diff --git a/kexec/mem_regions.c b/kexec/mem_regions.c
index 804984a..b01a5c8 100644
--- a/kexec/mem_regions.c
+++ b/kexec/mem_regions.c
@@ -55,3 +55,74 @@ int mem_regions_add(struct memory_ranges *ranges, unsigned 
long long base,
return 0;
 }
 
+static void mem_regions_remove(struct memory_ranges *ranges, int index)
+{
+   int tail_entries;
+
+   /* we are assured to have at least one entry */
+   ranges->size -= 1;
+
+   /* if we have following entries, shuffle them down one place */
+   tail_entries = ranges->size - index;
+   if (tail_entries)
+   memmove(ranges->ranges + index, ranges->ranges + index + 1,
+   tail_entries * sizeof(*ranges->ranges));
+
+   /* zero the new tail entry */
+   memset(ranges->ranges + ranges->size, 0, sizeof(*ranges->ranges));
+}
+
+/**
+ * mem_regions_exclude() - excludes a memory region from a set of memory ranges
+ * @ranges: memory ranges to exclude the region from
+ * @range: memory range to exclude
+ *
+ * Exclude a memory region from a set of memory ranges.  We assume that
+ * the region to be excluded is either wholely located within one of the
+ * memory ranges, or not at all.
+ */
+int mem_regions_exclude(struct memory_ranges *ranges,
+   const struct memory_range *range)
+{
+   int i, ret;
+
+   for (i = 0; i < ranges->size; i++) {
+   struct memory_range *r = ranges->ranges + i;
+
+   /*
+* We assume that crash area is fully contained in
+* some larger memory area.
+*/
+   if (r->start <= range->start && r->end >= range->end) {
+   if (r->start == range->start) {
+   if (r->end == range->end)
+   /* Remove this entry */
+   mem_regions_remove(ranges, i);
+   else
+   /* Shrink the start of this memory 
range */
+   r->start = range->end + 1;
+   } else if (r->end == range->end) {
+   /* Shrink the end of this memory range */
+   r->end = range->start - 1;
+   } else {
+   /*
+* Split this area into 2 smaller ones and
+* remove excluded range from between. First
+* create new entry for the remaining area.
+*/
+   ret = mem_regions_add(ranges, range->end + 1,
+ r->end - range->end, 0);
+   if (ret < 0)
+   return ret;
+
+   /*
+* Update this area to end before excluded
+* range.
+*/
+   r->end = range->start - 1;
+   break;
+   }
+   }
+   }
+   return 0;
+}
diff --git a/kexec/mem_regions.h b/kexec/mem_regions.h
index da7b5e8..ae9e972 100644
--- a/kexec/mem_regions.h
+++ b/kexec/mem_regions.h
@@ -2,9 +2,13 @@
 #define MEM_REGIONS_H
 
 struct memory_ranges;
+struct memory_range;
 
 void mem_regions_sort(struct memory_ranges *ranges);
 
+int mem_regions_exclude(struct memory_ranges *ranges,
+   const struct memory_range *range);
+
 int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
 unsigned long long length, int type);
 
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 17/32] arm: return proper error for missing crash kernel

[Russell King]

Return the proper error code (ENOCRASHKERNEL) for a missing crash
kernel region in /proc/iomem, so the error handling in kexec.c can
print the appropriate message.

Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kexec/arch/arm/kexec-zImage-arm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kexec/arch/arm/kexec-zImage-arm.c 
b/kexec/arch/arm/kexec-zImage-arm.c
index d85ab9b..4755f06 100644
--- a/kexec/arch/arm/kexec-zImage-arm.c
+++ b/kexec/arch/arm/kexec-zImage-arm.c
@@ -451,7 +451,7 @@ int zImage_arm_load(int argc, char **argv, const char *buf, 
off_t len,
 * No crash kernel memory reserved. We cannot do more
 * but just bail out.
 */
-   return -1;
+   return ENOCRASHKERNEL;
}
base = start;
} else {
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 25/32] arm: crashdump needs boot alias of crash kernel region

[Russell King]

When crashdumping, we need the boot memory alias of the crash kernel
region rather than the system view.  Arrange to check for the boot
alias of the crash kernel region first, and if found, use it instead
of the main alias.

Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kexec/arch/arm/kexec-zImage-arm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kexec/arch/arm/kexec-zImage-arm.c 
b/kexec/arch/arm/kexec-zImage-arm.c
index 4755f06..fdd2910 100644
--- a/kexec/arch/arm/kexec-zImage-arm.c
+++ b/kexec/arch/arm/kexec-zImage-arm.c
@@ -20,6 +20,7 @@
 #include "kexec-arm.h"
 #include "../../fs2dt.h"
 #include "crashdump-arm.h"
+#include "iomem.h"
 
 #define BOOT_PARAMS_SIZE 1536
 
@@ -446,7 +447,8 @@ int zImage_arm_load(int argc, char **argv, const char *buf, 
off_t len,
 * We put the dump capture kernel at the start of crashkernel
 * reserved memory.
 */
-   if (parse_iomem_single("Crash kernel\n", , )) {
+   if (parse_iomem_single(CRASH_KERNEL_BOOT, , ) &&
+   parse_iomem_single(CRASH_KERNEL, , )) {
/*
 * No crash kernel memory reserved. We cannot do more
 * but just bail out.
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 10/32] kexec: add generic helper to add to memory_regions

[Russell King]

Add a helper to add a memory range to a memory_regions array.

Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kexec/Makefile  |  4 
 kexec/mem_regions.c | 30 ++
 kexec/mem_regions.h |  9 +
 3 files changed, 43 insertions(+)
 create mode 100644 kexec/mem_regions.c
 create mode 100644 kexec/mem_regions.h

diff --git a/kexec/Makefile b/kexec/Makefile
index a758b4a..e2aee84 100644
--- a/kexec/Makefile
+++ b/kexec/Makefile
@@ -69,6 +69,10 @@ dist += kexec/fs2dt.c kexec/fs2dt.h
 $(ARCH)_FS2DT  =
 KEXEC_SRCS += $($(ARCH)_FS2DT)
 
+dist   += kexec/mem_regions.c kexec/mem_regions.h
+$(ARCH)_MEM_REGIONS=
+KEXEC_SRCS += $($(ARCH)_MEM_REGIONS)
+
 include $(srcdir)/kexec/arch/alpha/Makefile
 include $(srcdir)/kexec/arch/arm/Makefile
 include $(srcdir)/kexec/arch/i386/Makefile
diff --git a/kexec/mem_regions.c b/kexec/mem_regions.c
new file mode 100644
index 000..a4952ff
--- /dev/null
+++ b/kexec/mem_regions.c
@@ -0,0 +1,30 @@
+#include "kexec.h"
+#include "mem_regions.h"
+
+/**
+ * mem_regions_add() - add a memory region to a set of ranges
+ * @ranges: ranges to add the memory region to
+ * @max: maximum number of entries in memory region
+ * @base: base address of memory region
+ * @length: length of memory region in bytes
+ * @type: type of memory region
+ *
+ * Add the memory region to the set of ranges, and return %0 if successful,
+ * or %-1 if we ran out of space.
+ */
+int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
+unsigned long long length, int type)
+{
+   struct memory_range *range;
+
+   if (ranges->size >= ranges->max_size)
+   return -1;
+
+   range = ranges->ranges + ranges->size++;
+   range->start = base;
+   range->end = base + length - 1;
+   range->type = type;
+
+   return 0;
+}
+
diff --git a/kexec/mem_regions.h b/kexec/mem_regions.h
new file mode 100644
index 000..b9cfba1
--- /dev/null
+++ b/kexec/mem_regions.h
@@ -0,0 +1,9 @@
+#ifndef MEM_REGIONS_H
+#define MEM_REGIONS_H
+
+struct memory_ranges;
+
+int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
+unsigned long long length, int type);
+
+#endif
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 29/32] arm: add debug of reserved and coredump memory ranges

[Russell King]

Add debug of the reserved and coredump memory ranges for validation.

Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 25fdbe9..2dc8846 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -158,6 +158,10 @@ static int crash_get_memory_ranges(void)
return -1;
}
 
+   dbgprint_mem_range("Reserved memory ranges",
+  crash_reserved_rgns.ranges,
+  crash_reserved_rgns.size);
+
/*
 * Exclude all reserved memory from the usable memory regions.
 * We want to avoid dumping the crashkernel region itself.  Note
@@ -179,6 +183,9 @@ static int crash_get_memory_ranges(void)
 */
mem_regions_sort(_rgns);
 
+   dbgprint_mem_range("Coredump memory ranges",
+  usablemem_rgns.ranges, usablemem_rgns.size);
+
return 0;
 }
 
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 27/32] arm: add support for multiple reserved regions

[Russell King]

Add support for reserving multiple memory regions rather than just a
single region.

Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 66 --
 1 file changed, 25 insertions(+), 41 deletions(-)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 1a6ab88..9113f5e 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -55,6 +55,14 @@ struct memory_ranges usablemem_rgns = {
 /* memory range reserved for crashkernel */
 static struct memory_range crash_kernel_mem;
 
+/* reserved regions */
+#define CRASH_MAX_RESERVED_RANGES 2
+static struct memory_range crash_reserved_ranges[CRASH_MAX_RESERVED_RANGES];
+static struct memory_ranges crash_reserved_rgns = {
+   .max_size = CRASH_MAX_RESERVED_RANGES,
+   .ranges = crash_reserved_ranges,
+};
+
 static struct crash_elf_info elf_info = {
.class  = ELFCLASS32,
.data   = ELFDATANATIVE,
@@ -133,44 +141,6 @@ static int get_kernel_page_offset(struct kexec_info *info,
 }
 
 /**
- * crash_exclude_range() - excludes memory region reserved for crashkernel
- *
- * Function locates where crashkernel reserved memory is and removes that 
region
- * from the available memory regions.
- */
-static void crash_exclude_range(void)
-{
-   const struct memory_range *range = _kernel_mem;
-   int i;
-
-   for (i = 0; i < usablemem_rgns.size; i++) {
-   struct memory_range *r = usablemem_rgns.ranges + i;
-
-   /*
-* We assume that crash area is fully contained in
-* some larger memory area.
-*/
-   if (r->start <= range->start && r->end >= range->end) {
-   struct memory_range *new;
-   /*
-* Let's split this area into 2 smaller ones and
-* remove excluded range from between. First create
-* new entry for the remaining area.
-*/
-   new = usablemem_rgns.ranges + usablemem_rgns.size;
-   new->start = range->end + 1;
-   new->end = r->end;
-   usablemem_rgns.size++;
-   /*
-* Next update this area to end before excluded range.
-*/
-   r->end = range->start - 1;
-   break;
-   }
-   }
-}
-
-/**
  * crash_get_memory_ranges() - read system physical memory
  *
  * Function reads through system physical memory and stores found memory 
regions
@@ -181,16 +151,28 @@ static void crash_exclude_range(void)
  */
 static int crash_get_memory_ranges(void)
 {
+   int i;
+
if (usablemem_rgns.size < 1) {
errno = EINVAL;
return -1;
}
 
/*
-* Exclude memory reserved for crashkernel (this may result a split 
memory
-* region).
+* Exclude all reserved memory from the usable memory regions.
+* We want to avoid dumping the crashkernel region itself.  Note
+* that this may result memory regions in usablemem_rgns being
+* split.
 */
-   crash_exclude_range();
+   for (i = 0; i < crash_reserved_rgns.size; i++) {
+   if (mem_regions_exclude(_rgns,
+   _reserved_rgns.ranges[i])) {
+   fprintf(stderr,
+   "Error: Number of crash memory ranges excedeed 
the max limit\n");
+   errno = ENOMEM;
+   return -1;
+   }
+   }
 
/*
 * Make sure that the memory regions are sorted.
@@ -388,6 +370,8 @@ static int iomem_range_callback(void *UNUSED(data), int 
UNUSED(nr),
crash_kernel_mem.start = base;
crash_kernel_mem.end = base + length - 1;
crash_kernel_mem.type = RANGE_RAM;
+   return mem_regions_add(_reserved_rgns,
+  base, length, RANGE_RAM);
}
else if (strncmp(str, SYSTEM_RAM, strlen(SYSTEM_RAM)) == 0) {
return mem_regions_add(_rgns,
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 30/32] arm: fix type of phys_offset

[Russell King]

Some LPAE systems may have phys_offset above the 4GB mark.  Hence, we
need phys_offset to be a 64-bit integer.

Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 4 ++--
 kexec/arch/arm/crashdump-arm.h | 1 -
 kexec/arch/arm/phys_to_virt.c  | 4 +++-
 kexec/arch/arm/phys_to_virt.h  | 8 
 4 files changed, 13 insertions(+), 4 deletions(-)
 create mode 100644 kexec/arch/arm/phys_to_virt.h

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 2dc8846..2589582 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -33,6 +33,7 @@
 #include "../../mem_regions.h"
 #include "crashdump-arm.h"
 #include "iomem.h"
+#include "phys_to_virt.h"
 
 #if __BYTE_ORDER == __LITTLE_ENDIAN
 #define ELFDATANATIVE ELFDATA2LSB
@@ -70,7 +71,6 @@ static struct crash_elf_info elf_info = {
.page_offset= DEFAULT_PAGE_OFFSET,
 };
 
-unsigned long phys_offset;
 extern unsigned long long user_page_offset;
 
 /* Retrieve kernel _stext symbol virtual address from /proc/kallsyms */
@@ -293,7 +293,7 @@ int load_crashdump_segments(struct kexec_info *info, char 
*mod_cmdline)
 * region as PHYS_OFFSET.
 */
phys_offset = usablemem_rgns.ranges->start;
-   dbgprintf("phys_offset: %#lx\n", phys_offset);
+   dbgprintf("phys_offset: %#llx\n", phys_offset);
 
if (get_kernel_page_offset(info, _info))
return -1;
diff --git a/kexec/arch/arm/crashdump-arm.h b/kexec/arch/arm/crashdump-arm.h
index 7314960..6e87b13 100644
--- a/kexec/arch/arm/crashdump-arm.h
+++ b/kexec/arch/arm/crashdump-arm.h
@@ -16,7 +16,6 @@ extern struct memory_ranges usablemem_rgns;
 
 struct kexec_info;
 
-extern unsigned long phys_offset;
 extern int load_crashdump_segments(struct kexec_info *, char *);
 
 #ifdef __cplusplus
diff --git a/kexec/arch/arm/phys_to_virt.c b/kexec/arch/arm/phys_to_virt.c
index c2fe2ea..46a4f68 100644
--- a/kexec/arch/arm/phys_to_virt.c
+++ b/kexec/arch/arm/phys_to_virt.c
@@ -1,6 +1,8 @@
 #include "../../kexec.h"
 #include "../../crashdump.h"
-#include "crashdump-arm.h"
+#include "phys_to_virt.h"
+
+uint64_t phys_offset;
 
 /**
  * phys_to_virt() - translate physical address to virtual address
diff --git a/kexec/arch/arm/phys_to_virt.h b/kexec/arch/arm/phys_to_virt.h
new file mode 100644
index 000..b3147dd
--- /dev/null
+++ b/kexec/arch/arm/phys_to_virt.h
@@ -0,0 +1,8 @@
+#ifndef PHYS_TO_VIRT_H
+#define PHYS_TO_VIRT_H
+
+#include 
+
+extern uint64_t phys_offset;
+
+#endif
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 26/32] arm: rename crash_reserved_mem to crash_kernel_mem

[Russell King]

Rename crash_reserved_mem to crash_kernel_mem as we want to support
multiple reserved memory ranges.

Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index f2e6a0d..1a6ab88 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -53,7 +53,7 @@ struct memory_ranges usablemem_rgns = {
 };
 
 /* memory range reserved for crashkernel */
-static struct memory_range crash_reserved_mem;
+static struct memory_range crash_kernel_mem;
 
 static struct crash_elf_info elf_info = {
.class  = ELFCLASS32,
@@ -140,7 +140,7 @@ static int get_kernel_page_offset(struct kexec_info *info,
  */
 static void crash_exclude_range(void)
 {
-   const struct memory_range *range = _reserved_mem;
+   const struct memory_range *range = _kernel_mem;
int i;
 
for (i = 0; i < usablemem_rgns.size; i++) {
@@ -262,8 +262,8 @@ static void dump_memory_ranges(void)
return;
 
dbgprintf("crashkernel: [%#llx - %#llx] (%ldM)\n",
- crash_reserved_mem.start, crash_reserved_mem.end,
- (unsigned long)range_size(_reserved_mem) >> 20);
+ crash_kernel_mem.start, crash_kernel_mem.end,
+ (unsigned long)range_size(_kernel_mem) >> 20);
 
for (i = 0; i < usablemem_rgns.size; i++) {
struct memory_range *r = usablemem_rgns.ranges + i;
@@ -313,10 +313,10 @@ int load_crashdump_segments(struct kexec_info *info, char 
*mod_cmdline)
 * Ensure that the crash kernel memory range is sane. The crash kernel
 * must be located within memory which is visible during booting.
 */
-   if (crash_reserved_mem.end > ARM_MAX_VIRTUAL) {
+   if (crash_kernel_mem.end > ARM_MAX_VIRTUAL) {
fprintf(stderr,
"Crash kernel memory [0x%llx-0x%llx] is inaccessible at 
boot - unable to load crash kernel\n",
-   crash_reserved_mem.start, crash_reserved_mem.end);
+   crash_kernel_mem.start, crash_kernel_mem.end);
return -1;
}
 
@@ -349,8 +349,8 @@ int load_crashdump_segments(struct kexec_info *info, char 
*mod_cmdline)
 * regions to be aligned to SECTION_SIZE.
 */
elfcorehdr = add_buffer_phys_virt(info, buf, bufsz, bufsz, 1 << 20,
- crash_reserved_mem.start,
- crash_reserved_mem.end, -1, 0);
+ crash_kernel_mem.start,
+ crash_kernel_mem.end, -1, 0);
 
dbgprintf("elfcorehdr: %#lx\n", elfcorehdr);
cmdline_add_elfcorehdr(mod_cmdline, elfcorehdr);
@@ -360,7 +360,7 @@ int load_crashdump_segments(struct kexec_info *info, char 
*mod_cmdline)
 * prevents the dump capture kernel from using any other memory regions
 * which belong to the primary kernel.
 */
-   cmdline_add_mem(mod_cmdline, elfcorehdr - crash_reserved_mem.start);
+   cmdline_add_mem(mod_cmdline, elfcorehdr - crash_kernel_mem.start);
 
dump_memory_ranges();
dbgprintf("kernel command line: \"%s\"\n", mod_cmdline);
@@ -377,7 +377,7 @@ int load_crashdump_segments(struct kexec_info *info, char 
*mod_cmdline)
  * @length: size of the memory region
  *
  * This function is called for each memory range in /proc/iomem, stores
- * the location of the crash kernel range into @crash_reserved_mem, and
+ * the location of the crash kernel range into @crash_kernel_mem, and
  * stores the system RAM into @usablemem_rgns.
  */
 static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
@@ -385,9 +385,9 @@ static int iomem_range_callback(void *UNUSED(data), int 
UNUSED(nr),
unsigned long long length)
 {
if (strncmp(str, CRASH_KERNEL, strlen(CRASH_KERNEL)) == 0) {
-   crash_reserved_mem.start = base;
-   crash_reserved_mem.end = base + length - 1;
-   crash_reserved_mem.type = RANGE_RAM;
+   crash_kernel_mem.start = base;
+   crash_kernel_mem.end = base + length - 1;
+   crash_kernel_mem.type = RANGE_RAM;
}
else if (strncmp(str, SYSTEM_RAM, strlen(SYSTEM_RAM)) == 0) {
return mem_regions_add(_rgns,
@@ -407,5 +407,5 @@ int is_crashkernel_mem_reserved(void)
 {
kexec_iomem_for_each_line(NULL, iomem_range_callback, NULL);
 
-   return crash_reserved_mem.start != crash_reserved_mem.end;
+   return crash_kernel_mem.start != crash_kernel_mem.end;
 }
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 23/32] arm: move crash system RAM parsing earlier

[Russell King]

Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kexec/arch/arm/Makefile|  2 ++
 kexec/arch/arm/crashdump-arm.c | 51 --
 2 files changed, 11 insertions(+), 42 deletions(-)

diff --git a/kexec/arch/arm/Makefile b/kexec/arch/arm/Makefile
index 60e433a..71db8c3 100644
--- a/kexec/arch/arm/Makefile
+++ b/kexec/arch/arm/Makefile
@@ -7,6 +7,8 @@ arm_FS2DT  = kexec/fs2dt.c
 arm_FS2DT_INCLUDE  = -include $(srcdir)/kexec/arch/arm/crashdump-arm.h \
  -include $(srcdir)/kexec/arch/arm/kexec-arm.h
 
+arm_MEM_REGIONS= kexec/mem_regions.c
+
 arm_KEXEC_SRCS=  kexec/arch/arm/kexec-elf-rel-arm.c
 arm_KEXEC_SRCS+= kexec/arch/arm/kexec-zImage-arm.c
 arm_KEXEC_SRCS+= kexec/arch/arm/kexec-uImage-arm.c
diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index d6db566..f2e6a0d 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -30,6 +30,7 @@
 #include "../../kexec.h"
 #include "../../kexec-elf.h"
 #include "../../crashdump.h"
+#include "../../mem_regions.h"
 #include "crashdump-arm.h"
 #include "iomem.h"
 
@@ -132,39 +133,6 @@ static int get_kernel_page_offset(struct kexec_info *info,
 }
 
 /**
- * crash_range_callback() - callback called for each iomem region
- * @data: not used
- * @nr: not used
- * @str: name of the memory region
- * @base: start address of the memory region
- * @length: size of the memory region
- *
- * This function is called once for each memory region found in /proc/iomem. It
- * locates system RAM and places these into @crash_memory_ranges. Number of
- * memory regions is placed in @crash_memory_nr_ranges.
- */
-static int crash_range_callback(void *UNUSED(data), int UNUSED(nr),
-   char *str, unsigned long long base,
-   unsigned long long length)
-{
-   struct memory_range *range;
-
-   if (usablemem_rgns.size >= CRASH_MAX_MEMORY_RANGES)
-   return 1;
-
-   range = usablemem_rgns.ranges + usablemem_rgns.size;
-
-   if (strncmp(str, "System RAM\n", 11) == 0) {
-   range->start = base;
-   range->end = base + length - 1;
-   range->type = RANGE_RAM;
-   usablemem_rgns.size++;
-   }
-
-   return 0;
-}
-
-/**
  * crash_exclude_range() - excludes memory region reserved for crashkernel
  *
  * Function locates where crashkernel reserved memory is and removes that 
region
@@ -213,12 +181,6 @@ static void crash_exclude_range(void)
  */
 static int crash_get_memory_ranges(void)
 {
-   /*
-* First read all memory regions that can be considered as
-* system memory including the crash area.
-*/
-   kexec_iomem_for_each_line(NULL, crash_range_callback, NULL);
-
if (usablemem_rgns.size < 1) {
errno = EINVAL;
return -1;
@@ -414,8 +376,9 @@ int load_crashdump_segments(struct kexec_info *info, char 
*mod_cmdline)
  * @base: start address of the memory region
  * @length: size of the memory region
  *
- * This function is called for each memory range in /proc/iomem, and stores
- * the location of the crash kernel range into @crash_reserved_mem.
+ * This function is called for each memory range in /proc/iomem, stores
+ * the location of the crash kernel range into @crash_reserved_mem, and
+ * stores the system RAM into @usablemem_rgns.
  */
 static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
char *str, unsigned long long base,
@@ -426,6 +389,10 @@ static int iomem_range_callback(void *UNUSED(data), int 
UNUSED(nr),
crash_reserved_mem.end = base + length - 1;
crash_reserved_mem.type = RANGE_RAM;
}
+   else if (strncmp(str, SYSTEM_RAM, strlen(SYSTEM_RAM)) == 0) {
+   return mem_regions_add(_rgns,
+  base, length, RANGE_RAM);
+   }
return 0;
 }
 
@@ -434,7 +401,7 @@ static int iomem_range_callback(void *UNUSED(data), int 
UNUSED(nr),
  *
  * Check for the crashkernel reserved region in /proc/iomem, and return
  * true if it is present, or false otherwise. We use this to store the
- * location of this region.
+ * location of this region, and system RAM regions.
  */
 int is_crashkernel_mem_reserved(void)
 {
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 11/32] kexec: add mem_regions sorting implementation

[Russell King]

Add a mem_regions sorting implementation taken from the arm code.

Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kexec/mem_regions.c | 27 +++
 kexec/mem_regions.h |  2 ++
 2 files changed, 29 insertions(+)

diff --git a/kexec/mem_regions.c b/kexec/mem_regions.c
index a4952ff..804984a 100644
--- a/kexec/mem_regions.c
+++ b/kexec/mem_regions.c
@@ -1,6 +1,33 @@
+#include 
+
 #include "kexec.h"
 #include "mem_regions.h"
 
+static int mem_range_cmp(const void *a1, const void *a2)
+{
+   const struct memory_range *r1 = a1;
+   const struct memory_range *r2 = a2;
+
+   if (r1->start > r2->start)
+   return 1;
+   if (r1->start < r2->start)
+   return -1;
+
+   return 0;
+}
+
+/**
+ * mem_regions_sort() - sort ranges into ascending address order
+ * @ranges: ranges to sort
+ *
+ * Sort the memory regions into ascending address order.
+ */
+void mem_regions_sort(struct memory_ranges *ranges)
+{
+   qsort(ranges->ranges, ranges->size, sizeof(ranges->ranges),
+ mem_range_cmp);
+}
+
 /**
  * mem_regions_add() - add a memory region to a set of ranges
  * @ranges: ranges to add the memory region to
diff --git a/kexec/mem_regions.h b/kexec/mem_regions.h
index b9cfba1..da7b5e8 100644
--- a/kexec/mem_regions.h
+++ b/kexec/mem_regions.h
@@ -3,6 +3,8 @@
 
 struct memory_ranges;
 
+void mem_regions_sort(struct memory_ranges *ranges);
+
 int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
 unsigned long long length, int type);
 
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 28/32] arm: add support for boot-time crash kernel resource

[Russell King]

Add support for detecting and using the boot-time crash kernel
resource, which is needed for systems which have special boot-time
memory views, such as Keystone 2.

Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 9113f5e..25fdbe9 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -52,7 +52,7 @@ struct memory_ranges usablemem_rgns = {
.ranges = crash_memory_ranges,
 };
 
-/* memory range reserved for crashkernel */
+/* The boot-time physical memory range reserved for crashkernel region */
 static struct memory_range crash_kernel_mem;
 
 /* reserved regions */
@@ -366,13 +366,22 @@ static int iomem_range_callback(void *UNUSED(data), int 
UNUSED(nr),
char *str, unsigned long long base,
unsigned long long length)
 {
-   if (strncmp(str, CRASH_KERNEL, strlen(CRASH_KERNEL)) == 0) {
+   if (strncmp(str, CRASH_KERNEL_BOOT, strlen(CRASH_KERNEL_BOOT)) == 0) {
crash_kernel_mem.start = base;
crash_kernel_mem.end = base + length - 1;
crash_kernel_mem.type = RANGE_RAM;
return mem_regions_add(_reserved_rgns,
   base, length, RANGE_RAM);
}
+   else if (strncmp(str, CRASH_KERNEL, strlen(CRASH_KERNEL)) == 0) {
+   if (crash_kernel_mem.start == crash_kernel_mem.end) {
+   crash_kernel_mem.start = base;
+   crash_kernel_mem.end = base + length - 1;
+   crash_kernel_mem.type = RANGE_RAM;
+   }
+   return mem_regions_add(_reserved_rgns,
+  base, length, RANGE_RAM);
+   }
else if (strncmp(str, SYSTEM_RAM, strlen(SYSTEM_RAM)) == 0) {
return mem_regions_add(_rgns,
   base, length, RANGE_RAM);
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 15/32] arm: fix get_kernel_stext_sym() to close its file

[Russell King]

Fix get_kernel_stext_sym() so that it closes its file once it's
finsihed with it - there's no need to leak file descriptors.

Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index b523e5f..a390187 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -71,25 +71,34 @@ static unsigned long long get_kernel_stext_sym(void)
char sym[128];
char line[128];
FILE *fp;
-   unsigned long long vaddr;
+   unsigned long long vaddr = 0;
char type;
 
-   fp = fopen(kallsyms, "r");  if (!fp) {
+   fp = fopen(kallsyms, "r");
+   if (!fp) {
fprintf(stderr, "Cannot open %s\n", kallsyms);
return 0;
}
 
while(fgets(line, sizeof(line), fp) != NULL) {
-   if (sscanf(line, "%Lx %c %s", , , sym) != 3)
+   unsigned long long addr;
+
+   if (sscanf(line, "%Lx %c %s", , , sym) != 3)
continue;
+
if (strcmp(sym, stext) == 0) {
-   dbgprintf("kernel symbol %s vaddr = %16llx\n", stext, 
vaddr);
-   return vaddr;
+   dbgprintf("kernel symbol %s vaddr = %#llx\n", stext, 
addr);
+   vaddr = addr;
+   break;
}
}
 
-   fprintf(stderr, "Cannot get kernel %s symbol address\n", stext);
-   return 0;
+   fclose(fp);
+
+   if (vaddr == 0)
+   fprintf(stderr, "Cannot get kernel %s symbol address\n", stext);
+
+   return vaddr;
 }
 
 static int get_kernel_page_offset(struct kexec_info *info,
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 13/32] arm: fix pointer signedness warning in kexec-uImage-arm.c

[Russell King]

kexec/arch/arm/kexec-uImage-arm.c: In function 'uImage_arm_probe':
kexec/arch/arm/kexec-uImage-arm.c:14:2: warning: pointer targets in passing 
argument 1 of 'uImage_probe_kernel' differ in signedness [-Wpointer-sign]

Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kexec/arch/arm/kexec-uImage-arm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kexec/arch/arm/kexec-uImage-arm.c 
b/kexec/arch/arm/kexec-uImage-arm.c
index 03c2f4d..8e0a9ac 100644
--- a/kexec/arch/arm/kexec-uImage-arm.c
+++ b/kexec/arch/arm/kexec-uImage-arm.c
@@ -11,7 +11,8 @@
 
 int uImage_arm_probe(const char *buf, off_t len)
 {
-   return uImage_probe_kernel(buf, len, IH_ARCH_ARM);
+   return uImage_probe_kernel((const unsigned char *)buf, len,
+  IH_ARCH_ARM);
 }
 
 int uImage_arm_load(int argc, char **argv, const char *buf, off_t len,
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 21/32] arm: parse crash_reserved_mem early

[Russell King]

We parse the crash kernel memory region in several locations in the
kexec tools - once to check that there's a region, another time for
real when we're locating the memory regions to dump, and another
while loading the image.

Move the real parsing step to is_crashkernel_mem_reserved(), which
matches what x86 is doing.

Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 47 +++---
 kexec/arch/arm/iomem.h |  7 +++
 2 files changed, 42 insertions(+), 12 deletions(-)
 create mode 100644 kexec/arch/arm/iomem.h

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 195b43f..85afd9f 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -31,6 +31,7 @@
 #include "../../kexec-elf.h"
 #include "../../crashdump.h"
 #include "crashdump-arm.h"
+#include "iomem.h"
 
 #if __BYTE_ORDER == __LITTLE_ENDIAN
 #define ELFDATANATIVE ELFDATA2LSB
@@ -139,9 +140,8 @@ static int get_kernel_page_offset(struct kexec_info *info,
  * @length: size of the memory region
  *
  * This function is called once for each memory region found in /proc/iomem. It
- * locates system RAM and crashkernel reserved memory and places these to
- * variables: @crash_memory_ranges and @crash_reserved_mem. Number of memory
- * regions is placed in @crash_memory_nr_ranges.
+ * locates system RAM and places these into @crash_memory_ranges. Number of
+ * memory regions is placed in @crash_memory_nr_ranges.
  */
 static int crash_range_callback(void *UNUSED(data), int UNUSED(nr),
char *str, unsigned long long base,
@@ -159,10 +159,6 @@ static int crash_range_callback(void *UNUSED(data), int 
UNUSED(nr),
range->end = base + length - 1;
range->type = RANGE_RAM;
usablemem_rgns.size++;
-   } else if (strncmp(str, "Crash kernel\n", 13) == 0) {
-   crash_reserved_mem.start = base;
-   crash_reserved_mem.end = base + length - 1;
-   crash_reserved_mem.type = RANGE_RAM;
}
 
return 0;
@@ -424,12 +420,39 @@ int load_crashdump_segments(struct kexec_info *info, char 
*mod_cmdline)
return 0;
 }
 
-int is_crashkernel_mem_reserved(void)
+/**
+ * iomem_range_callback() - callback called for each iomem region
+ * @data: not used
+ * @nr: not used
+ * @str: name of the memory region (not NULL terminated)
+ * @base: start address of the memory region
+ * @length: size of the memory region
+ *
+ * This function is called for each memory range in /proc/iomem, and stores
+ * the location of the crash kernel range into @crash_reserved_mem.
+ */
+static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
+   char *str, unsigned long long base,
+   unsigned long long length)
 {
-   uint64_t start, end;
+   if (strncmp(str, CRASH_KERNEL, strlen(CRASH_KERNEL)) == 0) {
+   crash_reserved_mem.start = base;
+   crash_reserved_mem.end = base + length - 1;
+   crash_reserved_mem.type = RANGE_RAM;
+   }
+   return 0;
+}
 
-   if (parse_iomem_single("Crash kernel\n", , ) == 0)
-   return start != end;
+/**
+ * is_crashkernel_mem_reserved() - check for the crashkernel reserved region
+ *
+ * Check for the crashkernel reserved region in /proc/iomem, and return
+ * true if it is present, or false otherwise. We use this to store the
+ * location of this region.
+ */
+int is_crashkernel_mem_reserved(void)
+{
+   kexec_iomem_for_each_line(NULL, iomem_range_callback, NULL);
 
-   return 0;
+   return crash_reserved_mem.start != crash_reserved_mem.end;
 }
diff --git a/kexec/arch/arm/iomem.h b/kexec/arch/arm/iomem.h
new file mode 100644
index 000..81c593d
--- /dev/null
+++ b/kexec/arch/arm/iomem.h
@@ -0,0 +1,7 @@
+#ifndef IOMEM_H
+#define IOMEM_H
+
+#define SYSTEM_RAM "System RAM\n"
+#define CRASH_KERNEL   "Crash kernel\n"
+
+#endif
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 31/32] arm: clean up phys/page offset debug

[Russell King]

Clean up the physical and page offset debug prints.

Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 2589582..3b71267 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -136,7 +136,6 @@ static int get_kernel_page_offset(struct kexec_info *info,
user_page_offset);
}
elf_info->page_offset = stext_sym_addr & (~KVBASE_MASK);
-   dbgprintf("page_offset is set to %llx\n", elf_info->page_offset);
return 0;
 }
 
@@ -293,11 +292,13 @@ int load_crashdump_segments(struct kexec_info *info, char 
*mod_cmdline)
 * region as PHYS_OFFSET.
 */
phys_offset = usablemem_rgns.ranges->start;
-   dbgprintf("phys_offset: %#llx\n", phys_offset);
 
if (get_kernel_page_offset(info, _info))
return -1;
 
+   dbgprintf("phys offset = %#llx, page offset = %llx\n",
+ phys_offset, elf_info.page_offset);
+
/*
 * Ensure that the crash kernel memory range is sane. The crash kernel
 * must be located within memory which is visible during booting.
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 32/32] arm: report which ELF core format we will use

[Russell King]

Report which ELF core format will be used to create the template ELF
core dump in the debug information.

Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 3b71267..4a89b5e 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -315,6 +315,8 @@ int load_crashdump_segments(struct kexec_info *info, char 
*mod_cmdline)
last_ranges = 0;
 
if (crash_memory_ranges[last_ranges].end > UINT32_MAX) {
+   dbgprintf("Using 64-bit ELF core format\n");
+
/* for support LPAE enabled kernel*/
elf_info.class = ELFCLASS64;
 
@@ -323,6 +325,7 @@ int load_crashdump_segments(struct kexec_info *info, char 
*mod_cmdline)
 usablemem_rgns.size, , ,
 ELF_CORE_HEADER_ALIGN);
} else {
+   dbgprintf("Using 32-bit ELF core format\n");
err = crash_create_elf32_headers(info, _info,
 usablemem_rgns.ranges,
 usablemem_rgns.size, , ,
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 06/32] kdump: print mmap() offset in hex

[Russell King]

When mmap() fails, printing a large decimal number is mostly
meaningless - it's not obvious what it means.  Printing a hex number
is more obvious, because we can see whether it's over 32-bit, or not
page aligned.

Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kdump/kdump.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kdump/kdump.c b/kdump/kdump.c
index 34d2149..f34727f 100644
--- a/kdump/kdump.c
+++ b/kdump/kdump.c
@@ -37,7 +37,7 @@ static void *map_addr(int fd, unsigned long size, off_t 
offset)
 
result = mmap(0, len, PROT_READ, MAP_SHARED, fd, offset - map_offset);
if (result == MAP_FAILED) {
-   fprintf(stderr, "Cannot mmap " DEV_MEM " offset: %llu size: 
%lu: %s\n",
+   fprintf(stderr, "Cannot mmap " DEV_MEM " offset: %#llx size: 
%lu: %s\n",
(unsigned long long)offset, size, strerror(errno));
exit(5);
}
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 05/32] arm: fix kdump to work on LPAE systems

[Russell King]

We need to use 64-bit file IO when mapping system memory and the core
dump file as we may be running on a LPAE system, otherwise we risk
mapping memory we shouldn't, and causing a kernel oops:

Unhandled fault: asynchronous external abort (0x211) at 0x
pgd = edd2c740
[] *pgd=82ec98003, *pmd=82dcd2003, *pte=

Acked-by: Baoquan He <b...@redhat.com>
Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kexec/arch/arm/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kexec/arch/arm/Makefile b/kexec/arch/arm/Makefile
index 38137d7..60e433a 100644
--- a/kexec/arch/arm/Makefile
+++ b/kexec/arch/arm/Makefile
@@ -18,6 +18,9 @@ libfdt_SRCS += $(LIBFDT_SRCS:%=kexec/libfdt/%)
 
 arm_CPPFLAGS = -I$(srcdir)/kexec/libfdt
 
+# We want 64-bit file IO for kdump to work correctly on LPAE systems
+arm_CPPFLAGS += -D_FILE_OFFSET_BITS=64
+
 arm_KEXEC_SRCS += $(libfdt_SRCS)
 
 arm_UIMAGE = kexec/kexec-uImage.c
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 03/32] kdump: actually write out the memory

[Russell King]

Actually write out the memory rather than writing the notes a second
time.

Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kdump/kdump.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kdump/kdump.c b/kdump/kdump.c
index 99a1789..1f5b984 100644
--- a/kdump/kdump.c
+++ b/kdump/kdump.c
@@ -300,7 +300,7 @@ int main(int argc, char **argv)
for(i = 0; i < ehdr->e_phnum; i++) {
unsigned long long offset, size;
size_t wsize;
-   if (phdr[i].p_type != PT_NOTE) {
+   if (phdr[i].p_type == PT_NOTE) {
continue;
}
offset = phdr[i].p_offset;
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 04/32] kdump: fix kdump mapping

[Russell King]

When kdump tries to map the program header, it fails to take account
of ehdr->e_phoff being an offset from the start of the ELF "file",
which causes:

Cannot mmap /dev/mem offset: 64 size: 392: Invalid argument

Ensure that we take account of the start address when mapping this.

This fix has been extracted from a larger patch by Vitaly Andrianov
adding support for Keystone 2.

Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kdump/kdump.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kdump/kdump.c b/kdump/kdump.c
index 1f5b984..34d2149 100644
--- a/kdump/kdump.c
+++ b/kdump/kdump.c
@@ -284,7 +284,8 @@ int main(int argc, char **argv)
}

/* Get the program header */
-   phdr = map_addr(fd, sizeof(*phdr)*(ehdr->e_phnum), ehdr->e_phoff);
+   phdr = map_addr(fd, sizeof(*phdr)*(ehdr->e_phnum), 
+   start_addr + ehdr->e_phoff);
 
/* Collect up the notes */
note_bytes = 0;
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 22/32] arm: use generic mem_region sorting implementation

[Russell King]

Use the generic mem_region sorting implementation.

Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 16 +---
 1 file changed, 1 insertion(+), 15 deletions(-)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 85afd9f..d6db566 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -202,19 +202,6 @@ static void crash_exclude_range(void)
}
 }
 
-static int range_cmp(const void *a1, const void *a2)
-{
-   const struct memory_range *r1 = a1;
-   const struct memory_range *r2 = a2;
-
-   if (r1->start > r2->start)
-   return 1;
-   if (r1->start < r2->start)
-   return -1;
-
-   return 0;
-}
-
 /**
  * crash_get_memory_ranges() - read system physical memory
  *
@@ -246,8 +233,7 @@ static int crash_get_memory_ranges(void)
/*
 * Make sure that the memory regions are sorted.
 */
-   qsort(usablemem_rgns.ranges, usablemem_rgns.size,
- sizeof(*usablemem_rgns.ranges), range_cmp);
+   mem_regions_sort(_rgns);
 
return 0;
 }
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 02/32] kdump: fix multiple program header entries

[Russell King]

generate_new_headers() forgot to increment the program header pointer
after adding each program header from the kexec template. Fix it to
increment it correctly.

Without this, the program headers contain only the last entry, which
means we will be missing most of the kernel image in the dump.

Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kdump/kdump.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kdump/kdump.c b/kdump/kdump.c
index 3247a54..99a1789 100644
--- a/kdump/kdump.c
+++ b/kdump/kdump.c
@@ -192,6 +192,7 @@ static void *generate_new_headers(
}
memcpy(nphdr, [i], sizeof(*nphdr));
nphdr->p_offset = offset;
+   nphdr++;
offset += phdr[i].p_filesz;
}

-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 01/32] kdump: mmap() and munmap() only work on page-aligned quantites

[Russell King]

The man page for mmap() and munmap() says that mmap() and munmap()
only works for page-aligned addresses, sizes and offsets.  Arrange
to give these interfaces what they want.

Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kdump/kdump.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/kdump/kdump.c b/kdump/kdump.c
index 821ee7c..3247a54 100644
--- a/kdump/kdump.c
+++ b/kdump/kdump.c
@@ -25,22 +25,35 @@
 #define MAP_WINDOW_SIZE (64*1024*1024)
 #define DEV_MEM "/dev/mem"
 
+#define ALIGN_MASK(x,y) (((x) + (y)) & ~(y))
+#define ALIGN(x,y) ALIGN_MASK(x, (y) - 1)
+
 static void *map_addr(int fd, unsigned long size, off_t offset)
 {
+   unsigned long page_size = getpagesize();
+   unsigned long map_offset = offset & (page_size - 1);
+   size_t len = ALIGN(size + map_offset, page_size);
void *result;
-   result = mmap(0, size, PROT_READ, MAP_SHARED, fd, offset);
+
+   result = mmap(0, len, PROT_READ, MAP_SHARED, fd, offset - map_offset);
if (result == MAP_FAILED) {
fprintf(stderr, "Cannot mmap " DEV_MEM " offset: %llu size: 
%lu: %s\n",
(unsigned long long)offset, size, strerror(errno));
exit(5);
}
-   return result;
+   return result + map_offset;
 }
 
 static void unmap_addr(void *addr, unsigned long size)
 {
+   unsigned long page_size = getpagesize();
+   unsigned long map_offset = (uintptr_t)addr & (page_size - 1);
+   size_t len = ALIGN(size + map_offset, page_size);
int ret;
-   ret = munmap(addr, size);
+
+   addr -= map_offset;
+
+   ret = munmap(addr, len);
if (ret < 0) {
fprintf(stderr, "munmap failed: %s\n",
strerror(errno));
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 20/32] arm: add maximum number of memory ranges

[Russell King]

Add the maximum number of memory ranges to the list of usable memory
ranges, so that we don't have to carry this around.

Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 739c906..195b43f 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -46,8 +46,8 @@
  */
 static struct memory_range crash_memory_ranges[CRASH_MAX_MEMORY_RANGES];
 struct memory_ranges usablemem_rgns = {
-.size = 0,
-.ranges = crash_memory_ranges,
+   .max_size = CRASH_MAX_MEMORY_RANGES,
+   .ranges = crash_memory_ranges,
 };
 
 /* memory range reserved for crashkernel */
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 18/32] arm: report if crash kernel is out of bounds

[Russell King]

Report an error if the crash kernel memory region is outside of the
boot-view memory range - this can happen with systems such as
Keystone 2.

Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 11 +++
 kexec/arch/arm/crashdump-arm.h |  1 +
 2 files changed, 12 insertions(+)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index fcc4d42..739c906 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -365,6 +365,17 @@ int load_crashdump_segments(struct kexec_info *info, char 
*mod_cmdline)
if (get_kernel_page_offset(info, _info))
return -1;
 
+   /*
+* Ensure that the crash kernel memory range is sane. The crash kernel
+* must be located within memory which is visible during booting.
+*/
+   if (crash_reserved_mem.end > ARM_MAX_VIRTUAL) {
+   fprintf(stderr,
+   "Crash kernel memory [0x%llx-0x%llx] is inaccessible at 
boot - unable to load crash kernel\n",
+   crash_reserved_mem.start, crash_reserved_mem.end);
+   return -1;
+   }
+
last_ranges = usablemem_rgns.size - 1;
if (last_ranges < 0)
last_ranges = 0;
diff --git a/kexec/arch/arm/crashdump-arm.h b/kexec/arch/arm/crashdump-arm.h
index 2dbde04..7314960 100644
--- a/kexec/arch/arm/crashdump-arm.h
+++ b/kexec/arch/arm/crashdump-arm.h
@@ -9,6 +9,7 @@ extern "C" {
 #define DEFAULT_PAGE_OFFSET(0xc000)
 #define KVBASE_MASK(0x1ff)
 #define CRASH_MAX_MEMORY_RANGES32
+#define ARM_MAX_VIRTUALUINT32_MAX
 
 
 extern struct memory_ranges usablemem_rgns;
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 19/32] arm: add memory ranges debug

[Russell King]

Add the call to dbgprint_mem_range() into the ARM version of
get_memory_ranges().

Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kexec/arch/arm/kexec-arm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kexec/arch/arm/kexec-arm.c b/kexec/arch/arm/kexec-arm.c
index e47fc00..eeb27b4 100644
--- a/kexec/arch/arm/kexec-arm.c
+++ b/kexec/arch/arm/kexec-arm.c
@@ -70,6 +70,9 @@ int get_memory_ranges(struct memory_range **range, int 
*ranges,
fclose(fp);
*range = memory_range;
*ranges = memory_ranges;
+
+   dbgprint_mem_range("MEMORY RANGES", *range, *ranges);
+
return 0;
 }
 
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 08/32] kexec: add max_size to memory_ranges

[Russell King]

Many implementations statically allocate the memory range array, which
therefore will have a maximum allowable size.  Add this information to
the memory_ranges structure, so we don't have to carry it around.

Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kexec/kexec.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kexec/kexec.h b/kexec/kexec.h
index c02ac8f..9194f1c 100644
--- a/kexec/kexec.h
+++ b/kexec/kexec.h
@@ -142,6 +142,7 @@ struct memory_range {
 
 struct memory_ranges {
 unsigned int size;
+   unsigned int max_size;
 struct memory_range *ranges;
 };
 
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 07/32] kexec: fix warnings caused by selecting 64-bit file IO on 32-bit platforms

[Russell King]

Fix warnings caused by selecting 64-bit file IO on 32-bit platforms.

kexec/kexec.c:710:2: warning: format '%lx' expects argument of type 'long 
unsigned int', but argument 4 has type 'off_t' [-Wformat]
kexec/zlib.c:63:4: warning: format '%ld' expects argument of type 'long int', 
but argument 4 has type 'off_t' [-Wformat]
kexec/kexec-uImage.c:85:3: warning: format '%ld' expects argument of type 'long
int', but argument 2 has type 'off_t' [-Wformat]

Acked-by: Baoquan He <b...@redhat.com>
Signed-off-by: Russell King <r...@arm.linux.org.uk>
---
 kexec/kexec-uImage.c | 3 ++-
 kexec/kexec.c| 4 ++--
 kexec/zlib.c | 4 ++--
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/kexec/kexec-uImage.c b/kexec/kexec-uImage.c
index 9df601b..5e24629 100644
--- a/kexec/kexec-uImage.c
+++ b/kexec/kexec-uImage.c
@@ -82,7 +82,8 @@ int uImage_probe(const unsigned char *buf, off_t len, 
unsigned int arch)
if (be32_to_cpu(header.ih_size) > len - sizeof(header)) {
printf("uImage header claims that image has %d bytes\n",
be32_to_cpu(header.ih_size));
-   printf("we read only %ld bytes.\n", len - sizeof(header));
+   printf("we read only %lld bytes.\n",
+  (long long)len - sizeof(header));
return -1;
}
 #ifdef HAVE_LIBZ
diff --git a/kexec/kexec.c b/kexec/kexec.c
index f0bd527..500e5a9 100644
--- a/kexec/kexec.c
+++ b/kexec/kexec.c
@@ -707,8 +707,8 @@ static int my_load(const char *type, int fileind, int argc, 
char **argv,
/* slurp in the input kernel */
kernel_buf = slurp_decompress_file(kernel, _size);
 
-   dbgprintf("kernel: %p kernel_size: 0x%lx\n",
- kernel_buf, kernel_size);
+   dbgprintf("kernel: %p kernel_size: %#llx\n",
+ kernel_buf, (unsigned long long)kernel_size);
 
if (get_memory_ranges(_range, _ranges,
info.kexec_flags) < 0 || info.memory_ranges == 0) {
diff --git a/kexec/zlib.c b/kexec/zlib.c
index 7170ac3..95b6080 100644
--- a/kexec/zlib.c
+++ b/kexec/zlib.c
@@ -60,8 +60,8 @@ char *zlib_decompress_file(const char *filename, off_t 
*r_size)
if ((errno == EINTR) || (errno == EAGAIN))
continue;
_gzerror(fp, , );
-   dbgprintf("Read on %s of %ld bytes failed: %s\n",
-   filename, (allocated - size) + 0UL, 
msg);
+   dbgprintf("Read on %s of %d bytes failed: %s\n",
+ filename, (int)(allocated - size), msg);
size = 0;
goto fail;
}
-- 
1.9.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools v2 00/32] Keystone II updates for kexec tools

[Russell King - ARM Linux]

Here's the latest set of kexec-tools patches to support Keystone II
platforms, which work in conjunction with the kernel patches which
Andrew Morton has already taken.

Most of the patches have been reviewed, but there are a small number
which do not have Reviewed-by or Acked-by tags; these are due to
comments, which I've replied to, which have yet to have further
responses.

 kdump/kdump.c |  27 -
 kexec/Makefile|   4 +
 kexec/arch/arm/Makefile   |   5 +
 kexec/arch/arm/crashdump-arm.c| 247 +++---
 kexec/arch/arm/crashdump-arm.h|   2 +-
 kexec/arch/arm/iomem.h|   9 ++
 kexec/arch/arm/kexec-arm.c|   8 +-
 kexec/arch/arm/kexec-uImage-arm.c |   3 +-
 kexec/arch/arm/kexec-zImage-arm.c |   6 +-
 kexec/arch/arm/phys_to_virt.c |   6 +-
 kexec/arch/arm/phys_to_virt.h |   8 ++
 kexec/crashdump.h |   2 +-
 kexec/kexec-uImage.c  |   3 +-
 kexec/kexec.c |   4 +-
 kexec/kexec.h |   1 +
 kexec/mem_regions.c   | 128 
 kexec/mem_regions.h   |  15 +++
 kexec/phys_to_virt.c  |   2 +-
 kexec/zlib.c  |   4 +-
 19 files changed, 339 insertions(+), 145 deletions(-)


-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 2/8] ARM: kexec: advertise location of bootable RAM

[Russell King]

Advertise the location of bootable RAM to kexec-tools.  kexec needs to
know where it can place the kernel in RAM, and so be executable when
the system needs to jump into it.

Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
tag.

Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk>
---
 arch/arm/kernel/setup.c | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 19b25ad61385..612740788996 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -847,10 +847,29 @@ static void __init request_standard_resources(const 
struct machine_desc *mdesc)
kernel_data.end = virt_to_phys(_end - 1);
 
for_each_memblock(memory, region) {
+   phys_addr_t start = 
__pfn_to_phys(memblock_region_memory_base_pfn(region));
+   phys_addr_t end = 
__pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
+   unsigned long boot_alias_start;
+
+   /*
+* Some systems have a special memory alias which is only
+* used for booting.  We need to advertise this region to
+* kexec-tools so they know where bootable RAM is located.
+*/
+   boot_alias_start = phys_to_idmap(start);
+   if (arm_has_idmap_alias() && boot_alias_start != 
IDMAP_INVALID_ADDR) {
+   res = memblock_virt_alloc(sizeof(*res), 0);
+   res->name = "System RAM (boot alias)";
+   res->start = boot_alias_start;
+   res->end = phys_to_idmap(end);
+   res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+   request_resource(_resource, res);
+   }
+
res = memblock_virt_alloc(sizeof(*res), 0);
res->name  = "System RAM";
-   res->start = 
__pfn_to_phys(memblock_region_memory_base_pfn(region));
-   res->end = 
__pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
+   res->start = start;
+   res->end = end;
res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
request_resource(_resource, res);
-- 
2.1.0


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 8/8] ARM: kexec: fix kexec for Keystone 2

[Russell King]

Provide kexec with the boot view of memory by overriding the normal
kexec translation functions added in a previous patch.  We also need
to fix a call to memblock in machine_kexec_prepare() so that we
provide it with a running-view physical address rather than a boot-
view physical address.

Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk>
---
 arch/arm/include/asm/kexec.h| 24 
 arch/arm/kernel/machine_kexec.c |  2 +-
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/kexec.h b/arch/arm/include/asm/kexec.h
index c2b9b4bdec00..1869af6bac5c 100644
--- a/arch/arm/include/asm/kexec.h
+++ b/arch/arm/include/asm/kexec.h
@@ -53,6 +53,30 @@ static inline void crash_setup_regs(struct pt_regs *newregs,
 /* Function pointer to optional machine-specific reinitialization */
 extern void (*kexec_reinit)(void);
 
+static inline unsigned long phys_to_boot_phys(phys_addr_t phys)
+{
+   return phys_to_idmap(phys);
+}
+#define phys_to_boot_phys phys_to_boot_phys
+
+static inline phys_addr_t boot_phys_to_phys(unsigned long entry)
+{
+   return idmap_to_phys(entry);
+}
+#define boot_phys_to_phys boot_phys_to_phys
+
+static inline unsigned long page_to_boot_pfn(struct page *page)
+{
+   return page_to_pfn(page) + (arch_phys_to_idmap_offset >> PAGE_SHIFT);
+}
+#define page_to_boot_pfn page_to_boot_pfn
+
+static inline struct page *boot_pfn_to_page(unsigned long boot_pfn)
+{
+   return pfn_to_page(boot_pfn - (arch_phys_to_idmap_offset >> 
PAGE_SHIFT));
+}
+#define boot_pfn_to_page boot_pfn_to_page
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* CONFIG_KEXEC */
diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
index 59fd0e24c56b..b18c1ea56bed 100644
--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -57,7 +57,7 @@ int machine_kexec_prepare(struct kimage *image)
for (i = 0; i < image->nr_segments; i++) {
current_segment = >segment[i];
 
-   if (!memblock_is_region_memory(current_segment->mem,
+   if 
(!memblock_is_region_memory(idmap_to_phys(current_segment->mem),
   current_segment->memsz))
return -EINVAL;
 
-- 
2.1.0


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 6/8] kexec: allow architectures to override boot mapping

[Russell King]

kexec physical addresses are the boot-time view of the system.  For
certain ARM systems (such as Keystone 2), the boot view of the system
does not match the kernel's view of the system: the boot view uses a
special alias in the lower 4GB of the physical address space.

To cater for these kinds of setups, we need to translate between the
boot view physical addresses and the normal kernel view physical
addresses.  This patch extracts the current transation points into
linux/kexec.h, and allows an architecture to override the functions.

Due to the translations required, we unfortunately end up with six
translation functions, which are reduced down to four that the
architecture can override.

Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk>
---
 include/linux/kexec.h | 38 ++
 kernel/kexec.c|  3 ++-
 kernel/kexec_core.c   | 26 +-
 3 files changed, 53 insertions(+), 14 deletions(-)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 52a3a221bcb2..99cb9dac7909 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -318,6 +318,44 @@ int __weak arch_kexec_apply_relocations_add(const Elf_Ehdr 
*ehdr,
 int __weak arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr 
*sechdrs,
unsigned int relsec);
 
+#ifndef page_to_boot_pfn
+static inline unsigned long page_to_boot_pfn(struct page *page)
+{
+   return page_to_pfn(page);
+}
+#endif
+
+#ifndef boot_pfn_to_page
+static inline struct page *boot_pfn_to_page(unsigned long boot_pfn)
+{
+   return pfn_to_page(boot_pfn);
+}
+#endif
+
+#ifndef phys_to_boot_phys
+static inline unsigned long phys_to_boot_phys(phys_addr_t phys)
+{
+   return phys;
+}
+#endif
+
+#ifndef boot_phys_to_phys
+static inline phys_addr_t boot_phys_to_phys(unsigned long boot_phys)
+{
+   return boot_phys;
+}
+#endif
+
+static inline unsigned long virt_to_boot_phys(void *addr)
+{
+   return phys_to_boot_phys(__pa((unsigned long)addr));
+}
+
+static inline void *boot_phys_to_virt(unsigned long entry)
+{
+   return phys_to_virt(boot_phys_to_phys(entry));
+}
+
 #else /* !CONFIG_KEXEC_CORE */
 struct pt_regs;
 struct task_struct;
diff --git a/kernel/kexec.c b/kernel/kexec.c
index ee70aef5cd81..dd49d572a5e2 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -48,7 +48,8 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned 
long entry,
 
if (kexec_on_panic) {
/* Verify we have a valid entry point */
-   if ((entry < crashk_res.start) || (entry > crashk_res.end))
+   if ((entry < phys_to_boot_phys(crashk_res.start)) ||
+   (entry > phys_to_boot_phys(crashk_res.end)))
return -EADDRNOTAVAIL;
}
 
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index f9847e5822e6..d04940ccc58d 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -229,8 +229,8 @@ int sanity_check_segment_list(struct kimage *image)
mstart = image->segment[i].mem;
mend = mstart + image->segment[i].memsz - 1;
/* Ensure we are within the crash kernel limits */
-   if ((mstart < crashk_res.start) ||
-   (mend > crashk_res.end))
+   if ((mstart < phys_to_boot_phys(crashk_res.start)) ||
+   (mend > phys_to_boot_phys(crashk_res.end)))
return result;
}
}
@@ -354,7 +354,7 @@ static struct page 
*kimage_alloc_normal_control_pages(struct kimage *image,
pages = kimage_alloc_pages(KEXEC_CONTROL_MEMORY_GFP, order);
if (!pages)
break;
-   pfn   = page_to_pfn(pages);
+   pfn   = page_to_boot_pfn(pages);
epfn  = pfn + count;
addr  = pfn << PAGE_SHIFT;
eaddr = epfn << PAGE_SHIFT;
@@ -480,7 +480,7 @@ static int kimage_add_entry(struct kimage *image, 
kimage_entry_t entry)
return -ENOMEM;
 
ind_page = page_address(page);
-   *image->entry = virt_to_phys(ind_page) | IND_INDIRECTION;
+   *image->entry = virt_to_boot_phys(ind_page) | IND_INDIRECTION;
image->entry = ind_page;
image->last_entry = ind_page +
  ((PAGE_SIZE/sizeof(kimage_entry_t)) - 1);
@@ -535,13 +535,13 @@ void kimage_terminate(struct kimage *image)
 #define for_each_kimage_entry(image, ptr, entry) \
for (ptr = >head; (entry = *ptr) && !(entry & IND_DONE); \
ptr = (entry & IND_INDIRECTION) ? \
-   phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
+   boot_phys_to_virt((entry & PAGE_MASK)) : ptr +

[PATCH 5/8] kdump: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Russell King]

On PAE systems (eg, ARM LPAE) the vmcore note may be located above
4GB physical on 32-bit architectures, so we need a wider type than
"unsigned long" here.  Arrange for paddr_vmcoreinfo_note() to return
a phys_addr_t, thereby allowing it to be located above 4GB.

This makes no difference for kexec-tools, as they already assume a
64-bit type when reading from this file.

Acked-by: Baoquan He <b...@redhat.com>
Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk>
---
 arch/ia64/kernel/machine_kexec.c | 2 +-
 include/linux/kexec.h| 2 +-
 kernel/kexec_core.c  | 2 +-
 kernel/ksysfs.c  | 4 ++--
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/ia64/kernel/machine_kexec.c b/arch/ia64/kernel/machine_kexec.c
index b72cd7a07222..599507bcec91 100644
--- a/arch/ia64/kernel/machine_kexec.c
+++ b/arch/ia64/kernel/machine_kexec.c
@@ -163,7 +163,7 @@ void arch_crash_save_vmcoreinfo(void)
 #endif
 }
 
-unsigned long paddr_vmcoreinfo_note(void)
+phys_addr_t paddr_vmcoreinfo_note(void)
 {
return ia64_tpa((unsigned long)(char *)_note);
 }
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 1b32ab587f66..52a3a221bcb2 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -235,7 +235,7 @@ void crash_unmap_reserved_pages(void);
 void arch_crash_save_vmcoreinfo(void);
 __printf(1, 2)
 void vmcoreinfo_append_str(const char *fmt, ...);
-unsigned long paddr_vmcoreinfo_note(void);
+phys_addr_t paddr_vmcoreinfo_note(void);
 
 #define VMCOREINFO_OSRELEASE(value) \
vmcoreinfo_append_str("OSRELEASE=%s\n", value)
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index d719a4d0ef55..f9847e5822e6 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -1377,7 +1377,7 @@ void vmcoreinfo_append_str(const char *fmt, ...)
 void __weak arch_crash_save_vmcoreinfo(void)
 {}
 
-unsigned long __weak paddr_vmcoreinfo_note(void)
+phys_addr_t __weak paddr_vmcoreinfo_note(void)
 {
return __pa((unsigned long)(char *)_note);
 }
diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
index 152da4a48867..9f1920d2d0c6 100644
--- a/kernel/ksysfs.c
+++ b/kernel/ksysfs.c
@@ -128,8 +128,8 @@ KERNEL_ATTR_RW(kexec_crash_size);
 static ssize_t vmcoreinfo_show(struct kobject *kobj,
   struct kobj_attribute *attr, char *buf)
 {
-   return sprintf(buf, "%lx %x\n",
-  paddr_vmcoreinfo_note(),
+   phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
+   return sprintf(buf, "%pa %x\n", _base,
   (unsigned int)sizeof(vmcoreinfo_note));
 }
 KERNEL_ATTR_RO(vmcoreinfo);
-- 
2.1.0


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 3/8] kexec: don't invoke OOM-killer for control page allocation

[Russell King]

If we are unable to find a suitable page when allocating the control
page, do not invoke the OOM-killer: killing processes probably isn't
going to help.

Acked-by: Baoquan He <b...@redhat.com>
Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk>
---
 include/linux/kexec.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 2cc643c6e870..1b32ab587f66 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -41,7 +41,7 @@
 #endif
 
 #ifndef KEXEC_CONTROL_MEMORY_GFP
-#define KEXEC_CONTROL_MEMORY_GFP GFP_KERNEL
+#define KEXEC_CONTROL_MEMORY_GFP (GFP_KERNEL | __GFP_NORETRY)
 #endif
 
 #ifndef KEXEC_CONTROL_PAGE_SIZE
-- 
2.1.0


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 4/8] kexec: ensure user memory sizes do not wrap

[Russell King]

Ensure that user memory sizes do not wrap around when validating the
user input, which can lead to the following input validation working
incorrectly.

Acked-by: Baoquan He <b...@redhat.com>
Reviewed-by: Pratyush Anand <pan...@redhat.com>
Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk>
---
 kernel/kexec_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 8d34308ea449..d719a4d0ef55 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -169,6 +169,8 @@ int sanity_check_segment_list(struct kimage *image)
 
mstart = image->segment[i].mem;
mend   = mstart + image->segment[i].memsz;
+   if (mstart > mend)
+   return result;
if ((mstart & ~PAGE_MASK) || (mend & ~PAGE_MASK))
return result;
if (mend >= KEXEC_DESTINATION_MEMORY_LIMIT)
-- 
2.1.0


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 1/8] ARM: kdump: advertise boot aliased crash kernel resource

[Russell King]

Advertise a resource which describes where the crash kernel is located
in the boot view of RAM.  This allows kexec-tools to have this vital
information.

Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk>
---
 arch/arm/kernel/setup.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index d9317eec1eba..19b25ad61385 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -1003,9 +1003,25 @@ static void __init reserve_crashkernel(void)
(unsigned long)(crash_base >> 20),
(unsigned long)(total_mem >> 20));
 
+   /* The crashk resource must always be located in normal mem */
crashk_res.start = crash_base;
crashk_res.end = crash_base + crash_size - 1;
insert_resource(_resource, _res);
+
+   if (arm_has_idmap_alias()) {
+   /*
+* If we have a special RAM alias for use at boot, we
+* need to advertise to kexec tools where the alias is.
+*/
+   static struct resource crashk_boot_res = {
+   .name = "Crash kernel (boot alias)",
+   .flags = IORESOURCE_BUSY | IORESOURCE_MEM,
+   };
+
+   crashk_boot_res.start = phys_to_idmap(crash_base);
+   crashk_boot_res.end = crashk_boot_res.start + crash_size - 1;
+   insert_resource(_resource, _boot_res);
+   }
 }
 #else
 static inline void reserve_crashkernel(void) {}
-- 
2.1.0


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec