RE: [RFC PATCH 0/3] makedumpfile: about failing on arm64 with kernel > 5.4

RE: [RFC PATCH 0/3] makedumpfile: about failing on arm64 with kernel > 5.4

[HAGIO KAZUHITO(萩尾 一仁)]

Hi Alexander, Bhupesh,

Thank you for working on this, and sorry for the long delay.

For the 1/3 patch, Bhupesh and I got an offlist report that makedumpfile
could not be built with the patch in an old environment, which was a
similar error to kexec-tools patch [1].  And "make TARGET=aarch64" on
x86_64 also fails, though probably this is a rare usage.

Also there is the limitation that Alexander and I pointed out [2].

So my suggestion is to remove the part of fetching register value for
now.  This would not make makedumpfile support all arm64 kernels, so
it might be good to put it aside as a separate patch for distributions
with a description of the limitation.  or they can merge Bhupesh's kernel
commit bbdbc11804ff into their kernel.

Any other ideas?  e.g. a trial-and-error might be more acceptable
in this case..

Anyway, there has been a long time since I understood the arm64 changes,
I need to digest it again.  I might clean up your patches.
Please wait for a while.

[1] http://lists.infradead.org/pipermail/kexec/2020-September/021503.html
[2] http://lists.infradead.org/pipermail/kexec/2020-November/021797.html

Thanks,
Kazu

-----Original Message-----
> Hi Kazu, Bhupesh,
> 
> I am hitting the linear mapping swap issue with makedumpfile failing on
> arm64 Yocto Project qemuarm64 machine with 5.8 kernel as it was discussed
> several times on this mailing list:
> 
> root@qemuarm64:~# makedumpfile -c -F /proc/vmcore > /dev/null
> readpage_elf: Attempt to read non-existent page at 0x0.
> readmem: type_addr: 1, addr:440, size:8
> vaddr_to_paddr_arm64: Can't read pmd
> readmem: Can't convert a virtual address(ffffffc01107f94c) to physical address.
> readmem: type_addr: 0, addr:ffffffc01107f94c, size:390
> check_release: Can't get the address of system_utsname.
> 
> I've have tried Bhupesh's remaining third patch [1] from [2] series,
> it does help. But I am a bit hesitant to submit it to the Yocto Project,
> since Kazu pointed out [3] that this patch uses current kernel version to
> make decision how __pa is handled and it may mismatch the version where
> vmcore was collected, and in such case it may not operate correctly.
> 
> In this RFC series I have tried to implement Kazu's suggestion and use
> kernel version retrieved from OSRELEASE string from vmcoreinfo note. I
> wonder whether it will help to merge arm64 5.4+ makedumpfile fix? Is
> there anything else outstanding that prevents such merge?
> 
> My RFC patches series does include Bhupesh's patch [1], and I posted
> my modifications on top of it as separate patch for readability.
> 
> Thanks,
> Alexander
> 
> [1] http://lists.infradead.org/pipermail/kexec/2020-September/021336.html
> [2] http://lists.infradead.org/pipermail/kexec/2020-September/021333.html
> [3] http://lists.infradead.org/pipermail/kexec/2020-September/021488.html
> 
> Alexander Kamensky (2):
>   added way to determine kernel version that vmcore is from
>   arm64: use kernel version from OSRELEASE to determine linear mapping
>     position
> 
> Bhupesh Sharma (1):
>   makedumpfile/arm64: Add support for ARMv8.2-LVA (52-bit kernel VA
>     support)
> 
>  arch/arm64.c   | 229 ++++++++++++++++++++++++++++++++++++++++++-------
>  common.h       |  10 +++
>  makedumpfile.c |  23 +++++
>  makedumpfile.h |   6 +-
>  4 files changed, 234 insertions(+), 34 deletions(-)
> 
> --
> 2.26.2
> 


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

Re: [RFC PATCH 0/3] makedumpfile: about failing on arm64 with kernel > 5.4

[Alexander Kamensky]

Hi Bhupesh,

Appreciate your response while you're on holiday!

Please see responses inline below.

On Sun, Nov 22, 2020 at 8:57 PM Bhupesh SHARMA <bhupesh.linux@gmail.com> wrote:
>
> Hi Alexander,
>
> Thanks for the patchset.
> I am not sure why this new patchset is needed for makedumpfile
> upstream - if you need a separate patchset for Yocto please feel free
> to submit it to the Yocto list and Cc us.
>
> However for upstream makedumpfile project these are _probably_ not
> required - I have tested my patch on several arm64 boards and it works
> fine there.

Maybe I am missing something, I am new to makedumpfile.

Please consider the following use cases:

1) Primary kernel version is 5.8.1 but secondary kernel, that takes control
after primary crash, version is 5.2.1, according to your patch logic
makedumpfile running secondary, in populate_kernel_version function will issue
a uname call and gets 5.2.1 kernel_version. Acting on it makedumpfile reading
/proc/vmcore will handle __pa logic in the old pre 5.4 kernel way, but this
vmcore came from a 5.8.1 kernel and requires a new way of __pa handling.

2) Or in a similar case, consider a device with kernel 4.4 produced vmcore.
On the host machine running a 5.8 kernel, one would want to refilter vmcore
with different -d value. Since the current kernel version is 5.8 __pa
function will
use the new way, but the vmcore was created by an old kernel that requires the
old way of __pa handling.

My understanding is that this was the issue that Kazu pointed out in feedback
to your patch [1]. He wrote:

> The populate_kernel_version() uses uname(), so this means that there will
> be some cases that makedumpfile doesn't work with vmcores which were
> captured on other kernels than running one.  This is a rather big limitation
> especially to backward-compatibility test, and it would be better to
> avoid changing behavior depending on environment, not on data.
>
> Is there no room to avoid it?
>
> Just an idea, but can we use the OSRELEASE vmcoreinfo in ELF note first
> to determine the kernel version?  It's from init_uts_ns.name.release,
> why can't we use it?

I just implemented the suggestion.

Thanks,
Alexander

[1] http://lists.infradead.org/pipermail/kexec/2020-September/021488.html

>
> I will send the next version of my patch once I am back from my
> holidays later this week.
> If you see any breakage with the same, please feel free to report here
> with relevant logs and I can help further
>
> Thanks,
> Bhupesh
>
> On Mon, Nov 23, 2020 at 10:10 AM Alexander Kamensky
> <alexander.kamensky42@gmail.com> wrote:
> >
> > Hi Kazu, Bhupesh,
> >
> > I am hitting the linear mapping swap issue with makedumpfile failing on
> > arm64 Yocto Project qemuarm64 machine with 5.8 kernel as it was discussed
> > several times on this mailing list:
> >
> > root@qemuarm64:~# makedumpfile -c -F /proc/vmcore > /dev/null
> > readpage_elf: Attempt to read non-existent page at 0x0.
> > readmem: type_addr: 1, addr:440, size:8
> > vaddr_to_paddr_arm64: Can't read pmd
> > readmem: Can't convert a virtual address(ffffffc01107f94c) to physical address.
> > readmem: type_addr: 0, addr:ffffffc01107f94c, size:390
> > check_release: Can't get the address of system_utsname.
> >
> > I've have tried Bhupesh's remaining third patch [1] from [2] series,
> > it does help. But I am a bit hesitant to submit it to the Yocto Project,
> > since Kazu pointed out [3] that this patch uses current kernel version to
> > make decision how __pa is handled and it may mismatch the version where
> > vmcore was collected, and in such case it may not operate correctly.
> >
> > In this RFC series I have tried to implement Kazu's suggestion and use
> > kernel version retrieved from OSRELEASE string from vmcoreinfo note. I
> > wonder whether it will help to merge arm64 5.4+ makedumpfile fix? Is
> > there anything else outstanding that prevents such merge?
> >
> > My RFC patches series does include Bhupesh's patch [1], and I posted
> > my modifications on top of it as separate patch for readability.
> >
> > Thanks,
> > Alexander
> >
> > [1] http://lists.infradead.org/pipermail/kexec/2020-September/021336.html
> > [2] http://lists.infradead.org/pipermail/kexec/2020-September/021333.html
> > [3] http://lists.infradead.org/pipermail/kexec/2020-September/021488.html
> >
> > Alexander Kamensky (2):
> >   added way to determine kernel version that vmcore is from
> >   arm64: use kernel version from OSRELEASE to determine linear mapping
> >     position
> >
> > Bhupesh Sharma (1):
> >   makedumpfile/arm64: Add support for ARMv8.2-LVA (52-bit kernel VA
> >     support)
> >
> >  arch/arm64.c   | 229 ++++++++++++++++++++++++++++++++++++++++++-------
> >  common.h       |  10 +++
> >  makedumpfile.c |  23 +++++
> >  makedumpfile.h |   6 +-
> >  4 files changed, 234 insertions(+), 34 deletions(-)
> >
> > --
> > 2.26.2
> >
> >
> > _______________________________________________
> > kexec mailing list
> > kexec@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/kexec

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

Re: [RFC PATCH 0/3] makedumpfile: about failing on arm64 with kernel > 5.4

[Bhupesh SHARMA]

Hi Alexander,

Thanks for the patchset.
I am not sure why this new patchset is needed for makedumpfile
upstream - if you need a separate patchset for Yocto please feel free
to submit it to the Yocto list and Cc us.

However for upstream makedumpfile project these are _probably_ not
required - I have tested my patch on several arm64 boards and it works
fine there.

I will send the next version of my patch once I am back from my
holidays later this week.
If you see any breakage with the same, please feel free to report here
with relevant logs and I can help further

Thanks,
Bhupesh

On Mon, Nov 23, 2020 at 10:10 AM Alexander Kamensky
<alexander.kamensky42@gmail.com> wrote:
>
> Hi Kazu, Bhupesh,
>
> I am hitting the linear mapping swap issue with makedumpfile failing on
> arm64 Yocto Project qemuarm64 machine with 5.8 kernel as it was discussed
> several times on this mailing list:
>
> root@qemuarm64:~# makedumpfile -c -F /proc/vmcore > /dev/null
> readpage_elf: Attempt to read non-existent page at 0x0.
> readmem: type_addr: 1, addr:440, size:8
> vaddr_to_paddr_arm64: Can't read pmd
> readmem: Can't convert a virtual address(ffffffc01107f94c) to physical address.
> readmem: type_addr: 0, addr:ffffffc01107f94c, size:390
> check_release: Can't get the address of system_utsname.
>
> I've have tried Bhupesh's remaining third patch [1] from [2] series,
> it does help. But I am a bit hesitant to submit it to the Yocto Project,
> since Kazu pointed out [3] that this patch uses current kernel version to
> make decision how __pa is handled and it may mismatch the version where
> vmcore was collected, and in such case it may not operate correctly.
>
> In this RFC series I have tried to implement Kazu's suggestion and use
> kernel version retrieved from OSRELEASE string from vmcoreinfo note. I
> wonder whether it will help to merge arm64 5.4+ makedumpfile fix? Is
> there anything else outstanding that prevents such merge?
>
> My RFC patches series does include Bhupesh's patch [1], and I posted
> my modifications on top of it as separate patch for readability.
>
> Thanks,
> Alexander
>
> [1] http://lists.infradead.org/pipermail/kexec/2020-September/021336.html
> [2] http://lists.infradead.org/pipermail/kexec/2020-September/021333.html
> [3] http://lists.infradead.org/pipermail/kexec/2020-September/021488.html
>
> Alexander Kamensky (2):
>   added way to determine kernel version that vmcore is from
>   arm64: use kernel version from OSRELEASE to determine linear mapping
>     position
>
> Bhupesh Sharma (1):
>   makedumpfile/arm64: Add support for ARMv8.2-LVA (52-bit kernel VA
>     support)
>
>  arch/arm64.c   | 229 ++++++++++++++++++++++++++++++++++++++++++-------
>  common.h       |  10 +++
>  makedumpfile.c |  23 +++++
>  makedumpfile.h |   6 +-
>  4 files changed, 234 insertions(+), 34 deletions(-)
>
> --
> 2.26.2
>
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

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

[RFC PATCH 0/3] makedumpfile: about failing on arm64 with kernel > 5.4

[Alexander Kamensky]

Hi Kazu, Bhupesh,

I am hitting the linear mapping swap issue with makedumpfile failing on
arm64 Yocto Project qemuarm64 machine with 5.8 kernel as it was discussed
several times on this mailing list:

root@qemuarm64:~# makedumpfile -c -F /proc/vmcore > /dev/null
readpage_elf: Attempt to read non-existent page at 0x0.
readmem: type_addr: 1, addr:440, size:8
vaddr_to_paddr_arm64: Can't read pmd
readmem: Can't convert a virtual address(ffffffc01107f94c) to physical address.
readmem: type_addr: 0, addr:ffffffc01107f94c, size:390
check_release: Can't get the address of system_utsname.

I've have tried Bhupesh's remaining third patch [1] from [2] series,
it does help. But I am a bit hesitant to submit it to the Yocto Project,
since Kazu pointed out [3] that this patch uses current kernel version to
make decision how __pa is handled and it may mismatch the version where
vmcore was collected, and in such case it may not operate correctly.

In this RFC series I have tried to implement Kazu's suggestion and use
kernel version retrieved from OSRELEASE string from vmcoreinfo note. I
wonder whether it will help to merge arm64 5.4+ makedumpfile fix? Is
there anything else outstanding that prevents such merge?

My RFC patches series does include Bhupesh's patch [1], and I posted
my modifications on top of it as separate patch for readability.

Thanks,
Alexander

[1] http://lists.infradead.org/pipermail/kexec/2020-September/021336.html
[2] http://lists.infradead.org/pipermail/kexec/2020-September/021333.html
[3] http://lists.infradead.org/pipermail/kexec/2020-September/021488.html

Alexander Kamensky (2):
  added way to determine kernel version that vmcore is from
  arm64: use kernel version from OSRELEASE to determine linear mapping
    position

Bhupesh Sharma (1):
  makedumpfile/arm64: Add support for ARMv8.2-LVA (52-bit kernel VA
    support)

 arch/arm64.c   | 229 ++++++++++++++++++++++++++++++++++++++++++-------
 common.h       |  10 +++
 makedumpfile.c |  23 +++++
 makedumpfile.h |   6 +-
 4 files changed, 234 insertions(+), 34 deletions(-)

-- 
2.26.2


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