Re: [PATCH] x86: Fix PAGE_OFFSET for kernels since 4.20

[Baoquan He <bhe@redhat.com>]

On 08/30/19 at 03:35pm, Bhupesh Sharma wrote:
> On Fri, Aug 30, 2019 at 3:04 PM Donald Buczek <buczek@molgen.mpg.de> wrote:
> >
> > Dear Baoquan,
> >
> > On 8/30/19 11:23 AM, Baoquan He wrote:
> > > On 08/30/19 at 11:12am, Donald Buczek wrote:
> > >> Linux kernel commit d52888aa2753 ("x86/mm: Move LDT remap out of KASLR
> > >> region on 5-level paging") changed the base of the direct mapping
> > >> from 0xffff880000000000 to 0xffff888000000000. This was merged
> > >> into v4.20-rc2.
> > >
> > > A good catch and necessary fix, thanks.
> > >
> > > Does it have issue in makedumpfile?
> >
> > We don't use makedumpfile. We use `cp /proc/vmcore /mnt/crash.vmcore` in the panic kernel.
> 
> That shouldn't be a problem in makedumpfile as we have a generic way
> to calculate the PAGE_OFFSET value there from the PT_LOADs in the
> '/proc/kcore' file (which I mentioned in the other email conversation,
> see [0]):

Yeah, right.

> 
> static int
> get_page_offset_x86_64(void)
> {
> <..snip..>
>     if (get_num_pt_loads()) {
>         /*
>          * Linux 4.19 (only) adds KCORE_REMAP PT_LOADs, which have
>          * virt_start < __START_KERNEL_map, to /proc/kcore. In order
>          * not to select them, we select the last valid PT_LOAD.
>          */
>         for (i = 0;
>             get_pt_load(i, &phys_start, NULL, &virt_start, NULL);
>             i++) {
>             if (virt_start != NOT_KV_ADDR
>                     && virt_start < __START_KERNEL_map
>                     && phys_start != NOT_PADDR) {
>                 page_offset = virt_start - phys_start;
>             }
>         }
>         if (page_offset) {
>             info->page_offset = page_offset;
>             DEBUG_MSG("page_offset  : %lx (pt_load)\n",
>                 info->page_offset);
>             return TRUE;
>         }
>     }
> <..snip..>
> 
> Also as I mentioned in the other thread, I don't think adding
> different MACRO value for a kernel version is a long-term maintainable
> approach. Instead I am working on adding a similar functionality as
> present in makedumpfile to make the PAGE_OFFSET calculation generic.
> Only if we fail to calculate PAGE_OFFSET through a generic method
> should we fall back on MACRO values for backward compatibility.
> 
> I will try to post the patch for reviews by tomorrow.
> 
> [0]. https://lkml.org/lkml/2019/8/28/1060

Sounds a good idea, thanks for the effort.

Thanks
Baoquan

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec