> -----Original Message-----
> From: Pratyush Anand [mailto:[email protected]]
> Sent: 2018年5月30日 12:16
> To: Jin, Yanjiang <[email protected]>
> Cc: [email protected]; [email protected]; [email protected]
> Subject: Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel
>
> Hi Yanjiang,
>
> On Wed, May 30, 2018 at 8:33 AM, Jin, Yanjiang <[email protected]>
> wrote:
> > Hi Pratyush,
> >
> > Thanks for your help! but please see my reply inline.
> >
>
> [...]
>
> >> > If an application, for example, vmcore-dmesg, wants to access the
> >> > kernel symbol which is located in the last 2M address, it would
> >> > fail with the below error:
> >> >
> >> > "No program header covering vaddr 0xffff8017ffe90000 found kexec bug?"
> >>
> >> I think, fix might not be correct.
> >>
> >> Problem is in vmcore-dmesg and that should be fixed and not the kexec.
> >> See here (https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-
> >> tools.git/tree/vmcore-dmesg/vmcore-dmesg.c?id=HEAD#n261).
> >
> > Firstly, for my patch, vmcore-dmesg is just an auxiliary application to
> > help to
> reproduce this issue. The function, which is to generate vmcore, is the root
> cause.
>
> ...and the function which generates vmcore is not the kexec rather the
> secondary
> kernel.
>
> >
> > On the other hand, vmcore-dmesg is under kexec-tools, it has no a standalone
> git repo. Even we want to fix vmcore-dmesg, we still need to send the patch
> to
> kexec-tools, right?
>
> Sure. I meant `kexec` application. We have three applications in kexec-tools.
> `kexec`, `vmcore-dmesg` and `kdump`. [I hope kdump is useless and we are going
> to get rid off it very soon.]
>
> >
> > Yanjiang
> >
> >> How symbols are extracted from vmcore.
> >>
> >> You do have "NUMBER(PHYS_OFFSET)=" information in vmcore.
> >>
> >> You can probably see makedumpfile code, that how to extract
> >> information from "NUMBER".
> >
> > I have seen makedumpfile before, NUMBER(number) is just read a number
> from vmcore. But as I show before, the root issue is vmcore contains a wrong
> number, my patch is to fix the vmcore generating issue, we can't read vmcore
> at
> this point since we don't have vmcore yet.
>
> ..and IIUC, you were able to reach correctly till the end of secondary kernel
> where you tried vmcore-dmesg and then you had issue, right?
>
> How did you conclude that vmcore contains wrong number? It's unlikely, but if
> it
> does then we have problem somewhere in Linux kernel , not here.
Just use "readelf", I can find vmcore contains wrong number:
1. In the first kernel, "dmesg" and grep the last memory node as below, we can
see that the end of virtual memory is 0xffff801800000000:
memory : 0xffff800000200000 - 0xffff801800000000
# head -1 /proc/iomem
00200000-0021ffff : reserved
2. "kexec -p" as usual, then "readelf -a", I got different "VirtAddr "results
with/without my patch(0xffff80017fe00000 and 0xffff800180000000). So the end of
virtual memory is wrong without my patch.
(VirtAddr + MemSiz) = (0xffff80017fe00000 + 0x0000001680000000) =
0xFFFF8017FFE00000 != 0xffff801800000000
(VirtAddr + MemSiz) = (0xffff800180000000 + 0x0000001680000000) =
0xffff801800000000;
Since on my environment, iomem starts at 0x20000 as step 1 show, but
memstart_addr is 0.
# readelf -a incorrect-vmcore(Only show the last Program Header here, Without
my patch)
ELF Header:
........................
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
..............................................................................................................................................................
LOAD 0x0000000076d40000 0xffff80017fe00000 0x0000000180000000
0x0000001680000000 0x0000001680000000 RWE 0
# readelf -a correct-vmcore (Only show the last Program Header here, with my
patch)
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
.................................
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
.................................................................................................................................................................
LOAD 0x0000000076d40000 0xffff800180000000 0x0000000180000000
0x0000001680000000 0x0000001680000000 RWE 0
Yanjiang
>
> Have you tried to extract "PHYS_OFFSET" from vmcore either in vmcore-dmesg
> or in makedumpfile and found it not matching to the value of "PHYS_OFFSET"
> from first kernel?
>
> In my understanding flow is like this:
>
> - First kernel will have reserved area for secondary kernel, as well as for
> elfcore.
> - First kernel will embed all the vmcore information notes into elfcore (see
> crash_save_vmcoreinfo_init() -> arch_crash_save_vmcoreinfo()). Therefore, we
> will have PHYS_OFFSET, kimage_voffset and VA_BITS information for first kernel
> in vmcore, which is in separate memory and can be read by second kernel
> - elfcore will also have notes about all the other physical memory of first
> kernel
> which need to be copied by second kernel.
> - Now when crash happens, second kernel should have all the required info for
> reading symbols from first kernel's physical memory, no?
>
> >
> > NUMBER(number) = read_vmcoreinfo_ulong(STR_NUMBER(str_number))
> >
> > Yanjiang
> >
> >>
> >> Once you know the real PHYS_OFFSET (which could have been random if
> >> KASLR is enabled), you can fix the problem you are seeing.
> >
> > I have both validated with/without KASLR, all of them worked well after
> applying my patch.
>
> IMHO, even if that works it does not mean that its good a fix. We should try
> to
> find root cause. Moreover, you might not have /dev/mem available for all the
> configuration where KASLR is enabled.
Yes, I noticed this before. I plan to send v2 patch once my v1 patch satisfies
you and others. If " CONFIG_DEVMEM is not set", I will warn the user they may
get a wrong vmcore, then back to use the start of "/proc/iomem" as previous if
/dev/mem can't find.
Yanjiang
>
> Regards
> Pratyush
This email is intended only for the named addressee. It may contain information
that is confidential/private, legally privileged, or copyright-protected, and
you should handle it accordingly. If you are not the intended recipient, you do
not have legal rights to retain, copy, or distribute this email or its
contents, and should promptly delete the email and all electronic copies in
your system; do not retain copies in any media. If you have received this email
in error, please notify the sender promptly. Thank you.
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
