[Crash-utility] [营销邮件] Re: [External Mail][????] Re: ramdump support for va_bits_actual
Dave Anderson
anderson at redhat.com
Sun Apr 19 15:30:53 UTC 2020
----- Original Message -----
> Hi,Dave
>
> I don't quite understand how you said to read vmemmap,VMEMMAP_START is a
> macro definition,or it's a constant,in crash-utility vmemmap_start is a
> wrong value,this may cause arm64_IS_VMALLOC_ADDR return wrong status
I mean the kernel symbol "vmemmap", here in "arch/arm64/mm/init.c":
struct page *vmemmap __ro_after_init;
EXPORT_SYMBOL(vmemmap);
Doesn't it contain the resolved starting address?
> We can get physvirt_offset earlier,in my patch,after calling
> arm64_calc_phys_offset we can initialize physvirt_offset,in this
> time,kimage_offset,page_offset and phys_offset are ready,such as:
>
> @@ -391,6 +391,13 @@ arm64_init(int when)
>
> ms = machdep->machspec;
>
> + if (kernel_symbol_exists("physvirt_offset") &&
> + readmem(symbol_value("physvirt_offset"), KVADDR,
> + &value, sizeof(ulong), "physvirt_offset", QUIET|RETURN_ON_ERROR))
> + ms->physvirt_offset = value;
> + else
> + ms->physvirt_offset = ms->phys_offset -> ms->page_offset;
When the readmem() of symbol_value("physvirt_offset") is made, arm64_VTOP() will
be called with its virtual address, right?
Dave
> ________________________________________
> From: crash-utility-bounces at redhat.com <crash-utility-bounces at redhat.com> on
> behalf of Dave Anderson <anderson at redhat.com>
> Sent: Sunday, April 19, 2020 1:03
> To: Discussion list for crash utility usage, maintenance and development
> Subject: [营销邮件] Re: [Crash-utility] [External Mail][????] Re: ramdump support
> for va_bits_actual
>
> ----- Original Message -----
> > Hi
> > I made almost the same patch to fix the problem with arm64 in version
> > 5.4...
> >
> > One very small change can merged together,vmemmap_start has a little error:
> > [arch/arm64/include/asm/memory.h]
> > 56 #define VMEMMAP_START (-VMEMMAP_SIZE - SZ_2M)
> > in crash arm64.c
> > - vmemmap_start = (-vmemmap_size);
> > + vmemmap_start = (-vmemmap_size - MEGABYTES(2));
>
> Can't we just read the value of "vmemmap"? If not, what is the difference
> between the calculated value above and the value of vmemmap?
>
> >
> >
> > BTW,in arm64_VTOP,it's easier to use the physvirt_offset directly
> > @@ -1148,8 +1155,7 @@ arm64_VTOP(ulong addr)
> >
> > }
> >
> > if (addr >= machdep->machspec->page_offset)
> > - return machdep->machspec->phys_offset
> > - + (addr - machdep->machspec->page_offset);
> > + return (addr + machdep->machspec->physvirt_offset);
>
> Unfortunately that's not possible, because there is at least one arm64_VTOP()
> call *before* the new machdep->machspec->physvirt_offset gets initialized,
> which I presume is why Vinayak's patch checks whether it's non-zero first.
>
> Dave
>
>
>
> > ________________________________________
> > From: crash-utility-bounces at redhat.com <crash-utility-bounces at redhat.com>
> > on
> > behalf of Dave Anderson <anderson at redhat.com>
> > Sent: Saturday, April 18, 2020 0:32
> > To: Discussion list for crash utility usage, maintenance and development
> > Subject: [External Mail][????] Re: [Crash-utility] ramdump support for
> > va_bits_actual
> >
> > ----- Original Message -----
> > > Hi Dave,
> > >
> > > Noticed that raw ramdumps of 5.4 kernel aren't working with crash tip.
> > > With the patches attached, I could get it working. Please take a look.
> > >
> > > Thanks,
> > > Vinayak
> > >
> >
> > Hi Vinayak,
> >
> > A couple quick questions come to mind...
> >
> > First, I haven't checked all possible READMEM plugins, but for example, if
> > this
> > function is run on a live system, the -1 file descriptor would cause the
> > READMEM()
> > call to fail:
> >
> > static void
> > +arm64_calc_physvirt_offset(void)
> > +{
> > + struct machine_specific *ms = machdep->machspec;
> > + ulong physvirt_offset;
> > + struct syment *sp;
> > +
> > + ms->physvirt_offset = ms->phys_offset - ms->page_offset;
> > +
> > + if ((sp = kernel_symbol_search("physvirt_offset")) &&
> > + machdep->machspec->kimage_voffset) {
> > + if (READMEM(-1, &physvirt_offset, sizeof(physvirt_offset),
> > + sp->value, sp->value -
> > + machdep->machspec->kimage_voffset) > 0) {
> > + ms->physvirt_offset = physvirt_offset;
> > + }
> > + }
> > +
> > + if (CRASHDEBUG(1))
> > + fprintf(fp, "using %lx as physvirt_offset\n",
> > ms->physvirt_offset);
> > +}
> >
> > And here -- are you missing some brackets? (run "make warn")
> >
> > But regardless of that, why are you setting it back to 48 if it's greater
> > than 48?
> >
> > diff --git a/arm64.c b/arm64.c
> > index 31d6e90..04efc13 100644
> > --- a/arm64.c
> > +++ b/arm64.c
> > @@ -4011,6 +4011,7 @@ arm64_calc_virtual_memory_ranges(void)
> > struct machine_specific *ms = machdep->machspec;
> > ulong value, vmemmap_start, vmemmap_end, vmemmap_size, vmalloc_end;
> > char *string;
> > + int ret;
> > ulong PUD_SIZE = UNINITIALIZED;
> >
> > if (!machdep->machspec->CONFIG_ARM64_VA_BITS) {
> > @@ -4018,6 +4019,12 @@ arm64_calc_virtual_memory_ranges(void)
> > value = atol(string);
> > free(string);
> > machdep->machspec->CONFIG_ARM64_VA_BITS = value;
> > + } else if (kt->ikconfig_flags & IKCONFIG_AVAIL) {
> > + if ((ret =
> > get_kernel_config("CONFIG_ARM64_VA_BITS",
> > + &string)) == IKCONFIG_STR)
> > + machdep->machspec->CONFIG_ARM64_VA_BITS =
> > atol(string);
> > + if (machdep->machspec->CONFIG_ARM64_VA_BITS
> > >
> > 48)
> > +
> > machdep->machspec->CONFIG_ARM64_VA_BITS
> > = 48;
> > }
> > }
> >
> > Thanks,
> > Dave
> >
> > --
> > Crash-utility mailing list
> > Crash-utility at redhat.com
> > https://www.redhat.com/mailman/listinfo/crash-utility
> >
> > #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> > This e-mail and its attachments contain confidential information from
> > XIAOMI, which is intended only for the person or entity whose address is
> > listed above. Any use of the information contained herein in any way
> > (including, but not limited to, total or partial disclosure, reproduction,
> > or dissemination) by persons other than the intended recipient(s) is
> > prohibited. If you receive this e-mail in error, please notify the sender
> > by
> > phone or email immediately and delete it!******/#
> >
> > --
> > Crash-utility mailing list
> > Crash-utility at redhat.com
> > https://www.redhat.com/mailman/listinfo/crash-utility
>
> --
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
> #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from
> XIAOMI, which is intended only for the person or entity whose address is
> listed above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure, reproduction,
> or dissemination) by persons other than the intended recipient(s) is
> prohibited. If you receive this e-mail in error, please notify the sender by
> phone or email immediately and delete it!******/#
>
> --
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
More information about the Crash-utility
mailing list