Re: [Crash-utility] [营销邮件] Re: [External Mail][????] Re: ramdump support for va_bits_actual
- 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,
> + , 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-boun...@redhat.com on
> behalf of Dave Anderson
> 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-boun...@redhat.com
> > on
> > behalf of Dave Anderson
> > 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, _offset, sizeof(physvirt_offset),
> > + sp->value, sp->v
Re: [Crash-utility] [营销邮件] Re: [External Mail][????] Re: ramdump support for va_bits_actual
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,
+ , 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-boun...@redhat.com on
behalf of Dave Anderson
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-boun...@redhat.com on
> behalf of Dave Anderson
> 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, _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 r
