Handle pages filled with zero that are not stored in the ELF file
directly, but have addresses between p_filesz and p_memsz of a segment.
This allows makedumpfile to dump-dmesg from a previously makedumpfile-ed
vmcore where all 0-page were excluded (dump_level & 1) for example.
Signed-off-by:
On 01/27/16 at 02:48pm, Dmitry Safonov wrote:
> For allocation of kimage failure or kexec_prepare or load segments
> errors there is no need to keep crashkernel memory mapped.
> It will affect only s390 as map/unmap hook defined only for it.
> As on unmap s390 also changes os_info structure let's
On 2016/01/27 at 19:48, Dmitry Safonov wrote:
> For allocation of kimage failure or kexec_prepare or load segments
> errors there is no need to keep crashkernel memory mapped.
> It will affect only s390 as map/unmap hook defined only for it.
> As on unmap s390 also changes os_info structure let's
On Wed, 27 Jan 2016 14:48:31 +0300 Dmitry Safonov
wrote:
> For allocation of kimage failure or kexec_prepare or load segments
> errors there is no need to keep crashkernel memory mapped.
> It will affect only s390 as map/unmap hook defined only for it.
> As on unmap s390
For kexec reboot the bgrt image address could contains random data because
we have freed boot service areas in 1st kernel boot phase. One possible
result is kmalloc fail in efi_bgrt_init due to large random image size.
So change efi_late_init to avoid efi_bgrt_init in case kexec boot.
For allocation of kimage failure or kexec_prepare or load segments
errors there is no need to keep crashkernel memory mapped.
It will affect only s390 as map/unmap hook defined only for it.
As on unmap s390 also changes os_info structure let's check return code
and add info only on success.
Resent to the list.
The list does not like attachments, it seems.
Petr T
On Wed, 27 Jan 2016 08:58:21 +0100
Petr Tesarik wrote:
> Hello Atsushi-san,
>
> On Wed, 27 Jan 2016 02:21:57 +
> Atsushi Kumagai wrote:
>
> > Hello Ivan,
> >
> >