date:20191031

Re: [edk2-devel] How /sys/firmware/fdt getting created

2019-10-31 Thread Bhupesh Sharma

Hi Prabhakar,


On Fri, Nov 1, 2019 at 10:22 AM Prabhakar Kushwaha
 wrote:
>
> Hi Bhupesh,
>
> On Fri, Nov 1, 2019 at 1:59 AM Bhupesh Sharma  wrote:
> >
> > Hi Prabhakar,
> >
> > On Wed, Oct 30, 2019 at 1:47 PM Prabhakar Kushwaha
> >  wrote:
> > >
> > > On Wed, Oct 30, 2019 at 1:14 PM Ard Biesheuvel
> > >  wrote:
> > > >
> > > > On Wed, 30 Oct 2019 at 08:36, Prabhakar Kushwaha
> > > >  wrote:
> > > > >
> > > > > On Wed, Oct 30, 2019 at 12:43 PM Ard Biesheuvel
> > > > >  wrote:
> > > > > >
> > > > > > On Tue, 29 Oct 2019 at 18:17, Prabhakar Kushwaha
> > > > > >  wrote:
> > > > > > >
> > > > > > > Hi All,
> > > > > > >
> > > > > > > I am working on Ubuntu-18.04 with UEFI on ARM64(64 bit) platform. 
> > > > > > > The
> > > > > > > UEFI used is having ACPI tables.
> > > > > > >
> > > > > > > I am trying to understand where and how /sys/firmware/fdt is 
> > > > > > > getting
> > > > > > > created. is it created by UEFI or grub and passed to Linux?
> > > > > > >
> > > > > >
> > > > > > Neither. It is created by Linux itself.
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > Thanks Ard,
> > > > >
> > > > > Can you please point me the code where it is getting created.
> > > > > I want to add below in /sys/firmware/fdt.
> > > > >
> > > > > #size-cells = <0x02>;
> > > > > #address-cells = <0x02>;
> > > > >
> > > >
> > > > Actually, in your case it is GRUB not the kernel that creates the FDT.
> > > > It does this to pass the initrd information.
> > > >
> > > > So if you want to add these properties, you should add them there.
> > > >
> > > > Can you explain why doing this is necessary?
> > >
> > > I am trying to test kexec -p (kdump feature) on CentOS-release
> > > 7.7.1908 and Ubuntu-18.04 distributions.
> > >
> > >  "kexec -p" command show error on Ubuntu. While no error on CentOS
> > >
> > > CentOS:
> > > $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> > > -r`.img --reuse-cmdline
> > > $==> No error
> > >
> > > Ubuntu
> > > $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initrd.img-`uname
> > > -r` --reuse-cmdline
> > > $ kexec: elfcorehdr doesn't fit cells-size.
> > > $ kexec: setup_2nd_dtb failed.
> > > $ kexec: load failed.
> > > $ Cannot load /boot/vmlinuz-5.4.0-rc4+
> > >
> > > Note: Both CentOS and Ubuntu has Linux-5.4-rc4 tag.
> > >
> > > When i debugged further reason for Ubuntu error is due to
> > > address-cells and size-cells as "1"
> > > log from kexec tool :-
> > > load_crashdump_segments: elfcorehdr 0x7f7cbfc000-0x7f7cbff7ff
> > > read_1st_dtb: found name =dtb_sys  /sys/firmware/fdt
> > > get_cells_size: #address-cells:1 #size-cells:1
> > >
> > > On CentOS both values are "2".
> > > log from kexec tool :-
> > > load_crashdump_segments: elfcorehdr 0xbf98bf-0xbf98bf33ff
> > > read_1st_dtb: found nmae=dtb_sys /sys/firmware/fdt
> > > get_cells_size: #address-cells:2 #size-cells:2
> > >
> > > Note: Kexec tool read values from /sys/firmware/fdt.
> > >
> > > I am trying to figure out why 2 distributions showing different values.
> >
> > There are a couple of things I can suggest:
> >
> > 1. Try to see if it is a kexec-tools specific issue or is the kernel
> > itself passed an incorrectly fixed DTB (by grub?) with incorrect
> > #address-cells and #size-cells values (in the past I have seen
> > kexec-tools sometimes reports incorrect #address-cells and #size-cells
> > values, but they should be fixed in the newer kexec-tools versions):
> >
> > a). Can you check the kexec-tools version and share the same:
> > $ kexec -v
> >
> > b). Using 'dtc' tool, you can confirm if it reports a correct
> > #address-cells and #size-cells values:
> > # dtc -I dtb -O dts /sys/firmware/fdt | grep cells | less
> >
> > For e.g on my fedora arm64 system, it reports:
> > #address-cells = <0x2>;
> > #size-cells = <0x2>;
> >
> > 2a). If its not a kexec-tools specific issue, it is most probably a
> > bootloader (grub?) issue in your case:
> >
> > For e.g. I use the following grub2 on my Fedora arm64 board:
> > 
> > and 
> > 
> > contains the changes to send the correct #address-cells and
> > #size-cells values to Linux (and hence user-space tools like
> > kexec-tools later).
> >
> > I believe the same grub2 is used (backported) for CentOS, so things
> > should be fine there.
> >
> > 2b). I see that the latest devel branch of ubuntu grub2
> > () also contains this
> > fix, but I am not sure which grub2 version you have on your ubuntu
> > machine.
> >
>
> Ubuntu 18.04 has grub 2.02. When i migrated to grub 2.05, this issue
> is not there.
> Most probably the patch which is mentioned by Laszlo done the fix.
>
> http://git.savannah.gnu.org/cgit/grub.git/commit/?id=347210a5d5ce655b95315f320faa515afb723c11

That's good news. I am also glad its not a kexec-tools issues which I
need to fix :)
Thanks for sharing the update.

Regards,
Bhupesh

Re: [edk2-devel] How /sys/firmware/fdt getting created

2019-10-31 Thread Prabhakar Kushwaha

Hi Bhupesh,

On Fri, Nov 1, 2019 at 1:59 AM Bhupesh Sharma  wrote:
>
> Hi Prabhakar,
>
> On Wed, Oct 30, 2019 at 1:47 PM Prabhakar Kushwaha
>  wrote:
> >
> > On Wed, Oct 30, 2019 at 1:14 PM Ard Biesheuvel
> >  wrote:
> > >
> > > On Wed, 30 Oct 2019 at 08:36, Prabhakar Kushwaha
> > >  wrote:
> > > >
> > > > On Wed, Oct 30, 2019 at 12:43 PM Ard Biesheuvel
> > > >  wrote:
> > > > >
> > > > > On Tue, 29 Oct 2019 at 18:17, Prabhakar Kushwaha
> > > > >  wrote:
> > > > > >
> > > > > > Hi All,
> > > > > >
> > > > > > I am working on Ubuntu-18.04 with UEFI on ARM64(64 bit) platform. 
> > > > > > The
> > > > > > UEFI used is having ACPI tables.
> > > > > >
> > > > > > I am trying to understand where and how /sys/firmware/fdt is getting
> > > > > > created. is it created by UEFI or grub and passed to Linux?
> > > > > >
> > > > >
> > > > > Neither. It is created by Linux itself.
> > > > >
> > > > >
> > > > >
> > > >
> > > > Thanks Ard,
> > > >
> > > > Can you please point me the code where it is getting created.
> > > > I want to add below in /sys/firmware/fdt.
> > > >
> > > > #size-cells = <0x02>;
> > > > #address-cells = <0x02>;
> > > >
> > >
> > > Actually, in your case it is GRUB not the kernel that creates the FDT.
> > > It does this to pass the initrd information.
> > >
> > > So if you want to add these properties, you should add them there.
> > >
> > > Can you explain why doing this is necessary?
> >
> > I am trying to test kexec -p (kdump feature) on CentOS-release
> > 7.7.1908 and Ubuntu-18.04 distributions.
> >
> >  "kexec -p" command show error on Ubuntu. While no error on CentOS
> >
> > CentOS:
> > $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> > -r`.img --reuse-cmdline
> > $==> No error
> >
> > Ubuntu
> > $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initrd.img-`uname
> > -r` --reuse-cmdline
> > $ kexec: elfcorehdr doesn't fit cells-size.
> > $ kexec: setup_2nd_dtb failed.
> > $ kexec: load failed.
> > $ Cannot load /boot/vmlinuz-5.4.0-rc4+
> >
> > Note: Both CentOS and Ubuntu has Linux-5.4-rc4 tag.
> >
> > When i debugged further reason for Ubuntu error is due to
> > address-cells and size-cells as "1"
> > log from kexec tool :-
> > load_crashdump_segments: elfcorehdr 0x7f7cbfc000-0x7f7cbff7ff
> > read_1st_dtb: found name =dtb_sys  /sys/firmware/fdt
> > get_cells_size: #address-cells:1 #size-cells:1
> >
> > On CentOS both values are "2".
> > log from kexec tool :-
> > load_crashdump_segments: elfcorehdr 0xbf98bf-0xbf98bf33ff
> > read_1st_dtb: found nmae=dtb_sys /sys/firmware/fdt
> > get_cells_size: #address-cells:2 #size-cells:2
> >
> > Note: Kexec tool read values from /sys/firmware/fdt.
> >
> > I am trying to figure out why 2 distributions showing different values.
>
> There are a couple of things I can suggest:
>
> 1. Try to see if it is a kexec-tools specific issue or is the kernel
> itself passed an incorrectly fixed DTB (by grub?) with incorrect
> #address-cells and #size-cells values (in the past I have seen
> kexec-tools sometimes reports incorrect #address-cells and #size-cells
> values, but they should be fixed in the newer kexec-tools versions):
>
> a). Can you check the kexec-tools version and share the same:
> $ kexec -v
>
> b). Using 'dtc' tool, you can confirm if it reports a correct
> #address-cells and #size-cells values:
> # dtc -I dtb -O dts /sys/firmware/fdt | grep cells | less
>
> For e.g on my fedora arm64 system, it reports:
> #address-cells = <0x2>;
> #size-cells = <0x2>;
>
> 2a). If its not a kexec-tools specific issue, it is most probably a
> bootloader (grub?) issue in your case:
>
> For e.g. I use the following grub2 on my Fedora arm64 board:
> 
> and 
> 
> contains the changes to send the correct #address-cells and
> #size-cells values to Linux (and hence user-space tools like
> kexec-tools later).
>
> I believe the same grub2 is used (backported) for CentOS, so things
> should be fine there.
>
> 2b). I see that the latest devel branch of ubuntu grub2
> () also contains this
> fix, but I am not sure which grub2 version you have on your ubuntu
> machine.
>

Ubuntu 18.04 has grub 2.02. When i migrated to grub 2.05, this issue
is not there.
Most probably the patch which is mentioned by Laszlo done the fix.

http://git.savannah.gnu.org/cgit/grub.git/commit/?id=347210a5d5ce655b95315f320faa515afb723c11

Thanks
--pk

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

crash and makedumpfile with 5.3 missing memory in dump

2019-10-31 Thread Andi Kleen

Hi,

[I'm not sure if that is a crash or mkdumpfile problem]

I'm trying to use crash to read a makedumpfile vmcore from 5.3, but I always 
end up with an error when opening the dump. 

I'm using the latest github crash 

crash 7.2.7++
...
 crash: page excluded: kernel virtual address: 82110370  type:
 "possible"
 WARNING: cannot read cpu_possible_map
 crash: page excluded: kernel virtual address: 82110360  type:
 "present"
 WARNING: cannot read cpu_present_map
 crash: page excluded: kernel virtual address: 82110368  type:
 "online"
 WARNING: cannot read cpu_online_map
 crash: page excluded: kernel virtual address: 82110358  type:
 "active"
 WARNING: cannot read cpu_active_map
 crash: page excluded: kernel virtual address: 82011544  type:
 "init_uts_ns"
 crash: page excluded: kernel virtual address: 82110360  type:
 "cpu_present_map"
 crash: page excluded: kernel virtual address: 82110360  type:
 "cpu_present_map"
 WARNING: ORC unwinder: cannot read lookup_num_blocks
 crash: seek error: kernel virtual address: 88822dffb000  type:
 "memory section root table"

The dump is created with the latest makedumpfile release

makedumpfile: version 1.6.6 (released on 27 Jun 2019)

It complains that it doesn't support the kernel 

Any ideas? 

-Andi


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

Re: [edk2-devel] How /sys/firmware/fdt getting created

2019-10-31 Thread Bhupesh Sharma

Hi Prabhakar,

On Wed, Oct 30, 2019 at 1:47 PM Prabhakar Kushwaha
 wrote:
>
> On Wed, Oct 30, 2019 at 1:14 PM Ard Biesheuvel
>  wrote:
> >
> > On Wed, 30 Oct 2019 at 08:36, Prabhakar Kushwaha
> >  wrote:
> > >
> > > On Wed, Oct 30, 2019 at 12:43 PM Ard Biesheuvel
> > >  wrote:
> > > >
> > > > On Tue, 29 Oct 2019 at 18:17, Prabhakar Kushwaha
> > > >  wrote:
> > > > >
> > > > > Hi All,
> > > > >
> > > > > I am working on Ubuntu-18.04 with UEFI on ARM64(64 bit) platform. The
> > > > > UEFI used is having ACPI tables.
> > > > >
> > > > > I am trying to understand where and how /sys/firmware/fdt is getting
> > > > > created. is it created by UEFI or grub and passed to Linux?
> > > > >
> > > >
> > > > Neither. It is created by Linux itself.
> > > >
> > > >
> > > >
> > >
> > > Thanks Ard,
> > >
> > > Can you please point me the code where it is getting created.
> > > I want to add below in /sys/firmware/fdt.
> > >
> > > #size-cells = <0x02>;
> > > #address-cells = <0x02>;
> > >
> >
> > Actually, in your case it is GRUB not the kernel that creates the FDT.
> > It does this to pass the initrd information.
> >
> > So if you want to add these properties, you should add them there.
> >
> > Can you explain why doing this is necessary?
>
> I am trying to test kexec -p (kdump feature) on CentOS-release
> 7.7.1908 and Ubuntu-18.04 distributions.
>
>  "kexec -p" command show error on Ubuntu. While no error on CentOS
>
> CentOS:
> $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> -r`.img --reuse-cmdline
> $==> No error
>
> Ubuntu
> $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initrd.img-`uname
> -r` --reuse-cmdline
> $ kexec: elfcorehdr doesn't fit cells-size.
> $ kexec: setup_2nd_dtb failed.
> $ kexec: load failed.
> $ Cannot load /boot/vmlinuz-5.4.0-rc4+
>
> Note: Both CentOS and Ubuntu has Linux-5.4-rc4 tag.
>
> When i debugged further reason for Ubuntu error is due to
> address-cells and size-cells as "1"
> log from kexec tool :-
> load_crashdump_segments: elfcorehdr 0x7f7cbfc000-0x7f7cbff7ff
> read_1st_dtb: found name =dtb_sys  /sys/firmware/fdt
> get_cells_size: #address-cells:1 #size-cells:1
>
> On CentOS both values are "2".
> log from kexec tool :-
> load_crashdump_segments: elfcorehdr 0xbf98bf-0xbf98bf33ff
> read_1st_dtb: found nmae=dtb_sys /sys/firmware/fdt
> get_cells_size: #address-cells:2 #size-cells:2
>
> Note: Kexec tool read values from /sys/firmware/fdt.
>
> I am trying to figure out why 2 distributions showing different values.

There are a couple of things I can suggest:

1. Try to see if it is a kexec-tools specific issue or is the kernel
itself passed an incorrectly fixed DTB (by grub?) with incorrect
#address-cells and #size-cells values (in the past I have seen
kexec-tools sometimes reports incorrect #address-cells and #size-cells
values, but they should be fixed in the newer kexec-tools versions):

a). Can you check the kexec-tools version and share the same:
$ kexec -v

b). Using 'dtc' tool, you can confirm if it reports a correct
#address-cells and #size-cells values:
# dtc -I dtb -O dts /sys/firmware/fdt | grep cells | less

For e.g on my fedora arm64 system, it reports:
#address-cells = <0x2>;
#size-cells = <0x2>;

2a). If its not a kexec-tools specific issue, it is most probably a
bootloader (grub?) issue in your case:

For e.g. I use the following grub2 on my Fedora arm64 board:

and 
contains the changes to send the correct #address-cells and
#size-cells values to Linux (and hence user-space tools like
kexec-tools later).

I believe the same grub2 is used (backported) for CentOS, so things
should be fine there.

2b). I see that the latest devel branch of ubuntu grub2
() also contains this
fix, but I am not sure which grub2 version you have on your ubuntu
machine.

But you can do some debugging on the same by stopping the boot process
on the grub prompt and debugging grub further to check the version and
fixes done in fdt there. See
 for details.

Hope this helps.

Thanks,
Bhupesh

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

Re: [PATCH 1/2 RESEND v8] x86/kdump: always reserve the low 1M when the crashkernel option is specified

2019-10-31 Thread Borislav Petkov

On Thu, Oct 31, 2019 at 05:40:35PM +0800, lijiang wrote:
> Maybe it should be a separate patch to fix the old compile warnings as follow.
> And i should put the patch into this series.

Yes, maybe.

> commit d2091d1f4f67f1c38293b0e93fdbfefa766940cf (HEAD -> master)
> Author: Lianbo Jiang 
> Date:   Thu Oct 31 15:48:02 2019 +0800
> 
> kexec: Fix i386 build warnings that missed declaration of struct kimage
> 
> Kbuild test robot reported some build warnings, please refer to the
> Link below for details.

Explain here what the warnings are, why they trigger and how you're
fixing it. How a commit message should look like is also explained in
that document I pointed you at.

Refering to some link is not what we do in commit messages.

> Add a declaration of struct kimage to fix these compile warnings.
> 
> Fixes: dd5f726076cc ("kexec: support for kexec on panic using new system 
> call")
> Reported-by: kbuild test robot 
> Signed-off-by: Lianbo Jiang 
> Link: https://lkml.org/lkml/2019/10/30/833

*NEVER* use lkml.org or any other external URL for refering to mail
threads but *always* use our own

lkml.kernel.org/r/

redirector. See other tip commits for an example.

> > You can read
> > 
> > https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> > 
> > in the meantime, especially section
> > 
> > "9) Don't get discouraged - or impatient"
> > 
> > while waiting.
> 
> OK. Thanks.

And make sure to read that whole document and also have a look at the
process document

https://www.kernel.org/doc/html/latest/process/index.html

so that you can avoid such mistakes in the future.

Thx.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

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

Re: [edk2-devel] How /sys/firmware/fdt getting created

2019-10-31 Thread Laszlo Ersek

+Leif, comment at bottom

On 10/30/19 09:16, Prabhakar Kushwaha wrote:
> On Wed, Oct 30, 2019 at 1:14 PM Ard Biesheuvel
>  wrote:
>>
>> On Wed, 30 Oct 2019 at 08:36, Prabhakar Kushwaha
>>  wrote:
>>>
>>> On Wed, Oct 30, 2019 at 12:43 PM Ard Biesheuvel
>>>  wrote:

 On Tue, 29 Oct 2019 at 18:17, Prabhakar Kushwaha
  wrote:
>
> Hi All,
>
> I am working on Ubuntu-18.04 with UEFI on ARM64(64 bit) platform. The
> UEFI used is having ACPI tables.
>
> I am trying to understand where and how /sys/firmware/fdt is getting
> created. is it created by UEFI or grub and passed to Linux?
>

 Neither. It is created by Linux itself.



>>>
>>> Thanks Ard,
>>>
>>> Can you please point me the code where it is getting created.
>>> I want to add below in /sys/firmware/fdt.
>>>
>>> #size-cells = <0x02>;
>>> #address-cells = <0x02>;
>>>
>>
>> Actually, in your case it is GRUB not the kernel that creates the FDT.
>> It does this to pass the initrd information.
>>
>> So if you want to add these properties, you should add them there.
>>
>> Can you explain why doing this is necessary?
> 
> I am trying to test kexec -p (kdump feature) on CentOS-release
> 7.7.1908 and Ubuntu-18.04 distributions.
> 
>  "kexec -p" command show error on Ubuntu. While no error on CentOS
> 
> CentOS:
> $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> -r`.img --reuse-cmdline
> $==> No error
> 
> Ubuntu
> $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initrd.img-`uname
> -r` --reuse-cmdline
> $ kexec: elfcorehdr doesn't fit cells-size.
> $ kexec: setup_2nd_dtb failed.
> $ kexec: load failed.
> $ Cannot load /boot/vmlinuz-5.4.0-rc4+
> 
> Note: Both CentOS and Ubuntu has Linux-5.4-rc4 tag.
> 
> When i debugged further reason for Ubuntu error is due to
> address-cells and size-cells as "1"
> log from kexec tool :-
> load_crashdump_segments: elfcorehdr 0x7f7cbfc000-0x7f7cbff7ff
> read_1st_dtb: found name =dtb_sys  /sys/firmware/fdt
> get_cells_size: #address-cells:1 #size-cells:1
> 
> On CentOS both values are "2".
> log from kexec tool :-
> load_crashdump_segments: elfcorehdr 0xbf98bf-0xbf98bf33ff
> read_1st_dtb: found nmae=dtb_sys /sys/firmware/fdt
> get_cells_size: #address-cells:2 #size-cells:2
> 
> Note: Kexec tool read values from /sys/firmware/fdt.
> 
> I am trying to figure out why 2 distributions showing different values.

http://git.savannah.gnu.org/cgit/grub.git/commit/?id=347210a5d5ce655b95315f320faa515afb723c11

Ubuntu probably ships a grub version that lacks this commit.

(The commit was first released as part of upstream grub-2.04. I have no
idea what version of grub is shipped in the CentOS distro you mention
above -- it could be based upon upstream 2.04, or the upstream patch may
have been backported to CentOS.)

Thanks
Laszlo


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

Re: [PATCH 1/2 RESEND v8] x86/kdump: always reserve the low 1M when the crashkernel option is specified

2019-10-31 Thread lijiang

在 2019年10月31日 15:13, Borislav Petkov 写道:
> Please do not merge a 0day bot fix with another patch of yours which
> does not cause it in the first place. When you look at this patch alone,
> what do you think the Reported-by tag means, if anything at all?
> 
Thanks for your suggestions.

Maybe it should be a separate patch to fix the old compile warnings as follow.
And i should put the patch into this series.


commit d2091d1f4f67f1c38293b0e93fdbfefa766940cf (HEAD -> master)
Author: Lianbo Jiang 
Date:   Thu Oct 31 15:48:02 2019 +0800

kexec: Fix i386 build warnings that missed declaration of struct kimage

Kbuild test robot reported some build warnings, please refer to the
Link below for details.

Add a declaration of struct kimage to fix these compile warnings.

Fixes: dd5f726076cc ("kexec: support for kexec on panic using new system 
call")
Reported-by: kbuild test robot 
Signed-off-by: Lianbo Jiang 
Link: https://lkml.org/lkml/2019/10/30/833

diff --git a/arch/x86/include/asm/crash.h b/arch/x86/include/asm/crash.h
index 0acf5ee45a21..ef5638f641f2 100644
--- a/arch/x86/include/asm/crash.h
+++ b/arch/x86/include/asm/crash.h
@@ -2,6 +2,8 @@
 #ifndef _ASM_X86_CRASH_H
 #define _ASM_X86_CRASH_H
 
+struct kimage;
+
 int crash_load_segments(struct kimage *image);
 int crash_copy_backup_region(struct kimage *image);
 int crash_setup_memmap_entries(struct kimage *image,

> Also, it is not a "RESEND" if you change them. You can call them v8.1 or
> whatever to denote that the change is small.
> 
Thanks for your explanation in detail.

> Also, do not send v9 or v8.1 or whatever, immediately but wait for other
> reviews.

OK. Lets wait a week or more.

> You have sent these patches 4(!) times in this week alone. How
> would you feel if I hammer your inbox with patches on a daily basis?
>Probably because the change is small.

Anyway, so sorry, it seems inconsiderate.

> You can read
> 
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> 
> in the meantime, especially section
> 
> "9) Don't get discouraged - or impatient"
> 
> while waiting.

OK. Thanks.

Lianbo


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

Re: [PATCH 1/2 RESEND v8] x86/kdump: always reserve the low 1M when the crashkernel option is specified

2019-10-31 Thread Borislav Petkov

On Thu, Oct 31, 2019 at 11:35:16AM +0800, Lianbo Jiang wrote:
> Kdump kernel will reuse the first 640k region because the real mode
> trampoline has to work in this area. When the vmcore is dumped, the
> old memory in this area may be accessed, therefore, kernel has to
> copy the contents of the first 640k area to a backup region so that
> kdump kernel can read the old memory from the backup area of the
> first 640k area, which is done in the purgatory().
> 
> But, the current handling of copying the first 640k area runs into
> problems when SME is enabled, kernel does not properly copy these
> old memory to the backup area in the purgatory(), thereby, kdump
> kernel reads out the encrypted contents, because the kdump kernel
> must access the first kernel's memory with the encryption bit set
> when SME is enabled in the first kernel. Please refer to this link:
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204793
> 
> Finally, it causes the following errors, and the crash tool gets
> invalid pointers when parsing the vmcore.
> 
> crash> kmem -s|grep -i invalid
> kmem: dma-kmalloc-512: slab:d77680001c00 invalid 
> freepointer:a6086ac099f0c5a4
> kmem: dma-kmalloc-512: slab:d77680001c00 invalid 
> freepointer:a6086ac099f0c5a4
> crash>
> 
> To avoid the above errors, when the crashkernel option is specified,
> lets reserve the remaining low 1M memory(after reserving real mode
> memory) so that the allocated memory does not fall into the low 1M
> area, which makes us not to copy the first 640k content to a backup
> region in purgatory(). This indicates that it does not need to be
> included in crash dumps or used for anything except the processor
> trampolines that must live in the low 1M.
> 
> Signed-off-by: Lianbo Jiang 
> Reported-by: kbuild test robot 

Please do not merge a 0day bot fix with another patch of yours which
does not cause it in the first place. When you look at this patch alone,
what do you think the Reported-by tag means, if anything at all?

Also, it is not a "RESEND" if you change them. You can call them v8.1 or
whatever to denote that the change is small.

Also, do not send v9 or v8.1 or whatever, immediately but wait for other
reviews. You have sent these patches 4(!) times in this week alone. How
would you feel if I hammer your inbox with patches on a daily basis?

You can read

https://www.kernel.org/doc/html/latest/process/submitting-patches.html

in the meantime, especially section

"9) Don't get discouraged - or impatient"

while waiting.

Thx.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

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

Re: [edk2-devel] How /sys/firmware/fdt getting created

Re: [edk2-devel] How /sys/firmware/fdt getting created

crash and makedumpfile with 5.3 missing memory in dump

Re: [edk2-devel] How /sys/firmware/fdt getting created

Re: [PATCH 1/2 RESEND v8] x86/kdump: always reserve the low 1M when the crashkernel option is specified

Re: [edk2-devel] How /sys/firmware/fdt getting created

Re: [PATCH 1/2 RESEND v8] x86/kdump: always reserve the low 1M when the crashkernel option is specified

Re: [PATCH 1/2 RESEND v8] x86/kdump: always reserve the low 1M when the crashkernel option is specified

8 matches

Site Navigation

Mail list logo

Footer information