Re: [Crash-utility] ramdump support for va_bits_actual

2020-04-21 Thread vinayak menon 
Hi Dave, zhaoqianli

> Yeah, that looks reasonable.  But what about the parallel discussion re: 
> vmemmap_start?
>
>   https://www.redhat.com/archives/crash-utility/2020-April/msg00064.html

I have picked up the vmemmap_start as 4th patch. The physvirt_offset
based VTOP is already
part of patchset 1. I hope I have not missed anything from those
recommended by Zhaogianli.

>
> Can you send in an updated patch set with all fixes applied?

PFA.

Thanks,
Vinayak


0003-get-CONFIG_ARM64_VA_BITS-from-config.patch
Description: Binary data


0002-fix-the-calculation-of-_stext_vmlinux-for-ramdumps.patch
Description: Binary data


0001-fix-the-arm64-vtop-and-ptov-calculations.patch
Description: Binary data


0004-fix-vmemmap_start.patch
Description: Binary data
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Re: [Crash-utility] ramdump support for va_bits_actual

2020-04-20 Thread Dave Anderson 



- Original Message -
> Hi Dave,
> 
> On Sat, Apr 18, 2020 at 2:08 PM Dave Anderson  wrote:
> >
> >
> >
> > - 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:
> 
> 
> I changed it like this and it works for ramdump. I don't actually have
> a live setup to try this. Let me try
> to set up one.
> 
> diff --git a/arm64.c b/arm64.c
> index 04efc13..fce3f8e 100644
> --- a/arm64.c
> +++ b/arm64.c
> @@ -981,7 +981,7 @@ arm64_calc_physvirt_offset(void)
> 
> if ((sp = kernel_symbol_search("physvirt_offset")) &&
> machdep->machspec->kimage_voffset) {
> -   if (READMEM(-1, _offset, sizeof(physvirt_offset),
> +   if (READMEM(pc->mfd, _offset, 
> sizeof(physvirt_offset),
> sp->value, sp->value -
> machdep->machspec->kimage_voffset) > 0) {
> ms->physvirt_offset = physvirt_offset;
> 
> 
> >
> >  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")
> >
> 
> I did try "make warn" and it does not show any issues.Am I missing something?

I saw on a system provisioned with Fedora's latest and greatest gcc version.
I don't have the system available any more, but the warning message picked up
on the fact that your second if statement "was not guarded" by the if statement
above it.

> 
> > But regardless of that, why are you setting it back to 48 if it's greater
> > than 48?
> >
> 
> 
> I did that because machspec->CONFIG_ARM64_VA_BITS is used for calculation of
> vmemmap size. In kernel vmemmap size is calculated using VA_BITS_MIN and it is
> defined like this
> 
> #if VA_BITS > 48
> #define VA_BITS_MIN (48)
> #else
> #define VA_BITS_MIN (VA_BITS)
> #endif
> 
> But I realize now that its not the right thing to do, because 
> machspec->CONFIG_ARM64_VA_BITS
> is later used in arm64_calc_VA_BITS to verify machspec->VA_BITS. So
> what about this ?
> 
> diff --git a/arm64.c b/arm64.c
> index 04efc13..a35a30e 100644
> --- a/arm64.c
> +++ b/arm64.c
> @@ -4023,8 +4023,6 @@ arm64_calc_virtual_memory_ranges(void)
> if ((ret = get_kernel_config("CONFIG_ARM64_VA_BITS",
> )) == 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;
> }
> }
> 
> @@ -4049,7 +4047,12 @@ arm64_calc_virtual_memory_ranges(void)
>  #define STRUCT_PAGE_MAX_SHIFT   6
> 
> if (ms->VA_BITS_ACTUAL) {
> -   vmemmap_size = (1UL) << (ms->CONFIG_ARM64_VA_BITS - 
> machdep->pageshift - 1 + STRUCT_PAGE_MAX_SHIFT);
> +   ulong va_bits_min = 48;
> +
> +   if (machdep->machspec->CONFIG_ARM64_VA_BITS < 48)
> +   va_bits_min = ms->CONFIG_ARM64_VA_BITS;
> +
> +   vmemmap_size = (1UL) << (va_bits_min - machdep->pageshift - 1 
> + STRUCT_PAGE_MAX_SHIFT);
> vmalloc_end = (- PUD_SIZE - vmemmap_size - KILOBYTES(64));
> vmemmap_start = (-vmemmap_size);
> ms->vmalloc_end = vmalloc_end - 1;
> 

Yeah, that looks reasonable.  But what about the parallel discussion re: 
vmemmap_start?

  https://www.redhat.com/archives/crash-utility/2020-April/msg00064.html

Can you send in an updated patch set with all fixes applied?

Thanks,
  Dave



 


Shouldn't it be 

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Re: [Crash-utility] ramdump support for va_bits_actual

2020-04-20 Thread vinayak menon 
Hi Bhupesh,

On Sat, Apr 18, 2020 at 1:00 PM Bhupesh Sharma  wrote:
>
> Hi Vinayak,
>
> On Fri, Apr 17, 2020 at 8:34 PM vinayak menon  wrote:
> >
> > 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.
>
> Can you share some details/message-logs of the issue you are seeing?

The first issue was crash not resolving kimage_voffset, even with kaslr passed.

WARNING: kimage_voffset cannot be determined from the dumpfile.
  Try using the command line option: --machdep kimage_voffset=

One this was fixed, there were issue with VTOP for linear mapped addresses.

crash: read error: kernel virtual address: ff817f2ee628  type:
"IRQ stack pointer"
crash: read error: kernel virtual address: ff817f312380  type:
"memory section root table"

Later, there were issues with PTOV during FILL_PMD (read error "pmd page")

Thanks,
Vinayak

>
> Thanks,
> Bhupesh
>
>
> --
> Crash-utility mailing list
> Crash-utility@redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Re: [Crash-utility] ramdump support for va_bits_actual

2020-04-20 Thread vinayak menon 
Hi Dave,

On Sat, Apr 18, 2020 at 2:08 PM Dave Anderson  wrote:
>
>
>
> - 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:


I changed it like this and it works for ramdump. I don't actually have
a live setup to try this. Let me try
to set up one.

diff --git a/arm64.c b/arm64.c
index 04efc13..fce3f8e 100644
--- a/arm64.c
+++ b/arm64.c
@@ -981,7 +981,7 @@ arm64_calc_physvirt_offset(void)

if ((sp = kernel_symbol_search("physvirt_offset")) &&
machdep->machspec->kimage_voffset) {
-   if (READMEM(-1, _offset, sizeof(physvirt_offset),
+   if (READMEM(pc->mfd, _offset, sizeof(physvirt_offset),
sp->value, sp->value -
machdep->machspec->kimage_voffset) > 0) {
ms->physvirt_offset = physvirt_offset;


>
>  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")
>

I did try "make warn" and it does not show any issues.Am I missing something ?


> But regardless of that, why are you setting it back to 48 if it's greater 
> than 48?
>


I did that because machspec->CONFIG_ARM64_VA_BITS is used for calculation of
vmemmap size. In kernel vmemmap size is calculated using VA_BITS_MIN and it is
defined like this

#if VA_BITS > 48
#define VA_BITS_MIN (48)
#else
#define VA_BITS_MIN (VA_BITS)
#endif

But I realize now that its not the right thing to do, because
machspec->CONFIG_ARM64_VA_BITS
is later used in arm64_calc_VA_BITS to verify machspec->VA_BITS. So
what about this ?

diff --git a/arm64.c b/arm64.c
index 04efc13..a35a30e 100644
--- a/arm64.c
+++ b/arm64.c
@@ -4023,8 +4023,6 @@ arm64_calc_virtual_memory_ranges(void)
if ((ret = get_kernel_config("CONFIG_ARM64_VA_BITS",
)) == 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;
}
}

@@ -4049,7 +4047,12 @@ arm64_calc_virtual_memory_ranges(void)
 #define STRUCT_PAGE_MAX_SHIFT   6

if (ms->VA_BITS_ACTUAL) {
-   vmemmap_size = (1UL) << (ms->CONFIG_ARM64_VA_BITS -
machdep->pageshift - 1 + STRUCT_PAGE_MAX_SHIFT);
+   ulong va_bits_min = 48;
+
+   if (machdep->machspec->CONFIG_ARM64_VA_BITS < 48)
+   va_bits_min = ms->CONFIG_ARM64_VA_BITS;
+
+   vmemmap_size = (1UL) << (va_bits_min -
machdep->pageshift - 1 + STRUCT_PAGE_MAX_SHIFT);
vmalloc_end = (- PUD_SIZE - vmemmap_size - KILOBYTES(64));
vmemmap_start = (-vmemmap_size);
ms->vmalloc_end = vmalloc_end - 1;

Thanks,
Vinayak

>
> Thanks,
>   Dave
>
> --
> Crash-utility mailing list
> Crash-utility@redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Re: [Crash-utility] ramdump support for va_bits_actual

2020-04-17 Thread Dave Anderson 



- 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 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",
+   )) == 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@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Re: [Crash-utility] ramdump support for va_bits_actual

2020-04-17 Thread Bhupesh Sharma 
Hi Vinayak,

On Fri, Apr 17, 2020 at 8:34 PM vinayak menon  wrote:
>
> 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.

Can you share some details/message-logs of the issue you are seeing?

Thanks,
Bhupesh


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

[Crash-utility] ramdump support for va_bits_actual

2020-04-17 Thread vinayak menon 
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


0002-fix-the-calculation-of-_stext_vmlinux-for-ramdumps.patch
Description: Binary data


0003-get-CONFIG_ARM64_VA_BITS-from-config.patch
Description: Binary data


0001-fix-the-arm64-vtop-and-ptov-calculations.patch
Description: Binary data
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility