On Mon, Jun 20, 2016 at 11:02:22AM +0530, Pratyush Anand wrote:
> +Atsushi
>
> Hi Takahiro,
>
> On 16/06/2016:11:48:28 PM, Geoff Levand wrote:
> > From: AKASHI Takahiro
> >
> > For the current crash utility, we need to know, at least,
> > - kimage_voffset
> > - PHYS_OFFSET
> > to handle the
On 06/20/16 at 10:44pm, Thiago Jung Bauermann wrote:
> Hello,
>
> This patch series implements a mechanism which allows the kernel to pass on
> a buffer to the kernel that will be kexec'd. This buffer is passed as a
> segment which is added to the kimage when it is being prepared by
> kexec_file_l
>Pratyush Anand writes:
>
>> On 21/06/2016:10:05:42 AM, Vitaly Kuznetsov wrote:
>>> Pratyush Anand writes:
>>>
>>> > On 21/06/2016:05:43:29 AM, Atsushi Kumagai wrote:
>>> >> Hello Vitaly,
>>> >>
>>> >> >_count member was renamed to _refcount in linux commit 0139aa7b7fa12
>>> >> >("mm: rename _cou
On Tue, Jun 21, 2016 at 09:55:25AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux [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
The kexec_file_load system call needs to relocate the purgatory, so
factor out the module relocation code so that it can be shared.
This patch's purpose is to move the ELF relocation logic from
apply_relocate_add to elf_util_64.c with as few changes as
possible. The following changes were needed:
This purgatory implementation comes from kexec-tools, almost unchanged.
The only changes were that the sha256_regions global variable was
renamed to sha_regions to match what kexec_file_load expects, and to
use the sha256.c file from x86's purgatory to avoid adding yet another
SHA-256 implementati
When apply_relocate_add is called, modules are already loaded at their
final location in memory so Elf64_Shdr.sh_addr can be used for accessing
the section contents as well as the base address for relocations.
This is not the case for kexec's purgatory, because it will only be
copied to its final
This uses all the infrastructure built up by the previous patches
in the series to load an ELF vmlinux file and an initrd. It uses the
flattened device tree at initial_boot_params as a base and adjusts memory
reservations and its /chosen node for the next kernel.
elf64_apply_relocate_add was exten
A little endian kernel might need to kexec a big endian kernel (the
opposite is less likely but could happen as well), so we can't just cast
the buffer with the binary to ELF structs and use them as is done
elsewhere.
This patch adds functions which do byte-swapping as necessary when
populating th
kexec_add_buffer uses kexec_buf.buffer and kexec_buf.bufsz to pass along
its own arguments buffer and bufsz, but since they aren't used anywhere
else, it's pointless.
Signed-off-by: Thiago Jung Bauermann
Cc: Eric Biederman
Cc: kexec@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Acked-by:
Allow architectures to specify different memory walking functions for
kexec_add_buffer. Intel uses iomem to track reserved memory ranges,
but PowerPC uses the memblock subsystem.
Signed-off-by: Thiago Jung Bauermann
Cc: Eric Biederman
Cc: Dave Young
Cc: kexec@lists.infradead.org
Cc: linux-ker..
Hello,
This patch series implements the kexec_file_load system call on PowerPC.
This system call moves the reading of the kernel, initrd and the device tree
from the userspace kexec tool to the kernel. This is needed if you want to
do one or both of the following:
1. only allow loading of signed
Adds the basic machinery needed by kexec_file_load.
Signed-off-by: Josh Sklar
Signed-off-by: Thiago Jung Bauermann
Cc: kexec@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
---
arch/powerpc/Kconfig | 13 +
arch/powerpc/include/asm/systbl.h | 1 +
arch/powerp
kexec_locate_mem_hole will be used by the PowerPC kexec_file_load
implementation to find free memory for the purgatory stack.
Signed-off-by: Thiago Jung Bauermann
Cc: Eric Biederman
Cc: Dave Young
Cc: kexec@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
---
include/linux/kexec.h | 4 +++
* Russell King - ARM Linux [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
On Tue, Jun 21, 2016 at 03:57:20AM -0700, Tony Lindgren wrote:
> * Tony Lindgren [160621 03:41]:
> > * Russell King - ARM Linux [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 iss
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.
>
Hi Russell,
On 16/06/2016:12:13:03 AM, Russell King - ARM Linux wrote:
> 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
> > wrote:
> > > In fact, the apparent confusion over this reinforces my belief that we
> > > should _n
* Tony Lindgren [160621 03:41]:
> * Russell King - ARM Linux [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
* Russell King - ARM Linux [160621 02:50]:
> On Tue, Jun 21, 2016 at 12:43:21AM -0700, Tony Lindgren wrote:
> > Hi,
> >
> > * Russell King [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
Pratyush Anand writes:
> On 21/06/2016:10:05:42 AM, Vitaly Kuznetsov wrote:
>> Pratyush Anand writes:
>>
>> > On 21/06/2016:05:43:29 AM, Atsushi Kumagai wrote:
>> >> Hello Vitaly,
>> >>
>> >> >_count member was renamed to _refcount in linux commit 0139aa7b7fa12
>> >> >("mm: rename _count, fiel
On 21/06/2016:10:05:42 AM, Vitaly Kuznetsov wrote:
> Pratyush Anand writes:
>
> > On 21/06/2016:05:43:29 AM, Atsushi Kumagai wrote:
> >> Hello Vitaly,
> >>
> >> >_count member was renamed to _refcount in linux commit 0139aa7b7fa12
> >> >("mm: rename _count, field of the struct page, to _refcount
On Tue, Jun 21, 2016 at 12:43:21AM -0700, Tony Lindgren wrote:
> Hi,
>
> * Russell King [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 w
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 heade
Pratyush Anand writes:
> On 21/06/2016:05:43:29 AM, Atsushi Kumagai wrote:
>> Hello Vitaly,
>>
>> >_count member was renamed to _refcount in linux commit 0139aa7b7fa12
>> >("mm: rename _count, field of the struct page, to _refcount") and this
>> >broke makedumpfile. The reason for making the cha
Hi,
* Russell King [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 a
26 matches
Mail list logo
