Hi Yanjiang, On Wed, Jun 20, 2018 at 7:46 AM, Jin, Yanjiang <yanjiang....@hxt-semitech.com> wrote: > Hi James, Bhupesh, > > If /proc/kcore always exists in kexec/kdump, I think this issue can be fixed > easily. But it requires that Kexec/kdump have to rely on " > CONFIG_PROC_KCORE=y". > I am not sure if we can persuade Kexec-tools community to accept this.
Most distributions like Ubuntu and Fedora already enable CONFIG_PROC_KCORE by default, to support user-space tools like crash-utility and makedumpfile which can be used for 'live' debugging of a primary kernel (without the requirement of being in the secondary or crash kernel). For such cases. '/proc/kcore' and 'vmlinux' are the only available sources for PT_NOTE/PT_LOAD segments and kernel symbols respectively. Since we need to support all such existing user-space utilities (which work well with other archs like x86 and ppc64), we need to have a solution which works without modifying most of them - the rest (like kexec-tools) can be easily modified to follow the same approach. I would share some patches soon on the same lines both for kernel and user-space. Thanks, Bhupesh >> -----Original Message----- >> From: Bhupesh Sharma [mailto:bhsha...@redhat.com] >> Sent: 2018年6月19日 19:58 >> To: James Morse <james.mo...@arm.com> >> Cc: Jin, Yanjiang <yanjiang....@hxt-semitech.com>; Will Deacon >> <will.dea...@arm.com>; Mark Rutland <mark.rutl...@arm.com>; Ard >> Biesheuvel <ard.biesheu...@linaro.org>; Catalin Marinas >> <catalin.mari...@arm.com>; Kexec Mailing List <kexec@lists.infradead.org>; >> AKASHI Takahiro <takahiro.aka...@linaro.org>; Bhupesh SHARMA >> <bhupesh.li...@gmail.com>; linux-arm-kernel <linux-arm- >> ker...@lists.infradead.org> >> Subject: Re: [PATCH] arm64/mm: Introduce a variable to hold base address of >> linear region >> >> Hi James, >> >> On Tue, Jun 19, 2018 at 4:56 PM, James Morse <james.mo...@arm.com> wrote: >> > Hi Bhupesh, >> > >> > On 19/06/18 11:37, Bhupesh Sharma wrote: >> >> On Tue, Jun 19, 2018 at 3:46 PM, James Morse <james.mo...@arm.com> >> wrote: >> >>> On 19/06/18 10:57, Jin, Yanjiang wrote: >> >>>>> -----Original Message----- >> >>>>> From: Will Deacon [mailto:will.dea...@arm.com] >> >>>>> Sent: 2018年6月19日 17:41 >> >>>>> To: Jin, Yanjiang <yanjiang....@hxt-semitech.com> >> >>>>> Cc: James Morse <james.mo...@arm.com>; Bhupesh Sharma >> >>>>> <bhsha...@redhat.com>; Mark Rutland <mark.rutl...@arm.com>; Ard >> >>>>> Biesheuvel <ard.biesheu...@linaro.org>; Catalin Marinas >> >>>>> <catalin.mari...@arm.com>; Kexec Mailing List >> >>>>> <kexec@lists.infradead.org>; AKASHI Takahiro >> >>>>> <takahiro.aka...@linaro.org>; Bhupesh SHARMA >> >>>>> <bhupesh.li...@gmail.com>; linux-arm-kernel <linux-arm- >> >>>>> ker...@lists.infradead.org> >> >>>>> Subject: Re: [PATCH] arm64/mm: Introduce a variable to hold base >> >>>>> address of linear region >> > >> >>>>>>>> It is hard to know all above in kexec-tools now. Originally I >> >>>>>>>> planned to read memstart_addr's value from "/dev/mem", but >> >>>>>>>> someone thought not all Kernels enable "/dev/mem", we'd better >> >>>>>>>> find a more generic approach. So we want to get some >> >>>>>>>> suggestions from ARM kernel >> >>>>> community. >> >>>>>>>> Can we export this variable in Kernel side through sysconf() or >> >>>>>>>> other similar methods? Or someone can provide an effect way to >> >>>>>>>> get memstart_addr's value? >> >>>>>>> >> >>>>>>> I thought the suggestion from James was to expose this via an >> >>>>>>> ELF NOTE in kcore and vmcore (or in the header directly if >> >>>>>>> that's possible, but I'm >> >>>>> not sure about it)? >> >>>>>> >> >>>>>> Thanks for your reply firstly. But same as DEVMEM, kcore is not a >> >>>>>> must-have, so we can't depend on it. >> >>>>> >> >>>>> Neither is KEXEC. We can select PROC_KCORE from KEXEC if it helps. >> >>>>> >> >>>>>> On the other hand, phys_to_virt() is called during generating >> >>>>>> vmcore in Kexec-tools, vmcore also can't help this issue. >> >>>>> >> >>>>> I don't understand this part. If you have the vmcore in your hand, >> >>>>> why can't you grok the pv offset from the note and use that in >> phys_to_virt()? >> >>>> >> >>>> It is a chicken-and-egg issue. >> >>>> phys_to virt() is for crashdump setup. To generate vmcore, we must >> >>>> call phys_to_virt(). At this point, no vmcore exists. >> >>> >> >>> Its needed for the parts of the ELF header that kexec-tools >> >>> generates at kdump load time? >> >>> >> >>> So adding this pv_offset to the key=value data >> >>> crash_save_vmcoreinfo_init() saves isn't available early enough? >> > >> >> Yes, one case where it is not actually available early enough for >> >> makedumpfile usage is if we are determining the PT_NOTE contents from >> >> the '/proc/kcore' on a 'live' system >> > >> >> int set_kcore_vmcoreinfo(uint64_t vmcoreinfo_addr, uint64_t >> >> vmcoreinfo_len) >> >> >> >> { >> >> >> >> <snip..> >> >> kvaddr = (ulong)vmcoreinfo_addr + PAGE_OFFSET; >> >> >> >> } >> > >> > You are trying to read the vmcoreinfo through /proc/kcore given >> > knowledge of its physical address. >> > >> > I'm suggesting adding the contents of vmcoreinfo as a PT_NOTE section >> > of /proc/kcore's ELF header. No special knowledge necessary, any >> > elf-parser should be able to dump the values. >> > >> > >> >> Now the problem at hand is to determine the offset at which the >> >> pv_offset (key=value data pair) lies in the '/proc/kcore' (I assume >> >> that when you mentioned above and earlier about adding this pair to >> >> the elfnotes you meant both the vmcoreinfo and 'proc/kcore'), as we >> >> can have 'n' number of PT_LOAD segments. >> > >> > It looks like there is already a NOTE section with core info in there: >> > | # readelf -l /proc/kcore >> > | >> > | Elf file type is CORE (Core file) >> > | Entry point 0x0 >> > | There are 16 program headers, starting at offset 64 >> > | >> > | Program Headers: >> > | Type Offset VirtAddr PhysAddr >> > | FileSiz MemSiz Flags Align >> > | NOTE 0x00000000000003c0 0x0000000000000000 0x0000000000000000 >> > | 0x0000000000001114 0x0000000000000000 0x0 >> > >> > I assume we can add more notes without breaking the existing user... >> > >> > (and it looks like there are some broken __pa(kernel symbol) users in >> > there. >> >> Thanks for your inputs. >> >> I am working on fixes on the above lines for kernel and user-space tools >> (like >> makedumpfile, crash-utility and kexec-tools). >> >> I will post some RFC patches on the same lines (or come back in case I get >> stuck >> somewhere) shortly. >> >> Thanks, >> Bhupesh > > > > 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 kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
