Re: [营销邮件] Re: [External Mail][????] Re: ramdump support for va_bits_actual

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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;

________________________________________
From: crash-utility-bounces@xxxxxxxxxx <crash-utility-bounces@xxxxxxxxxx> on behalf of Dave Anderson <anderson@xxxxxxxxxx>
Sent: Sunday, April 19, 2020 1:03
To: Discussion list for crash utility usage,    maintenance and development
Subject: [营销邮件] Re:  [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@xxxxxxxxxx <crash-utility-bounces@xxxxxxxxxx> on
> behalf of Dave Anderson <anderson@xxxxxxxxxx>
> Sent: Saturday, April 18, 2020 0:32
> To: Discussion list for crash utility usage,    maintenance and development
> Subject: [External Mail][????] Re:  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@xxxxxxxxxx
> 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@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/crash-utility

--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility




[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux