Re: Incorrect vmcoreinfo KERNELOFFSET after "s390/boot: Rework deployment of the kernel image"

On Tue, Jul 09, 2024 at 09:21:41PM +0200, Petr Tesařík wrote:

Hi Petr,
...
> > I would say to some degree there is also inconsisten with regard
> > to /proc/ files existence:
> > /proc/kcore    is enabled by CONFIG_PROC_KCORE option, while
> > /proc/kallsyms is enabled by CONFIG_KALLSYMS option.
> > I assume drgn expects both files exist and does not work otherwise.
> > 
> > Nevertheless, it is still possible to refer to only one file for
> > symbol resolution and use an always-present symbol. E.g _stext
> > could be leveraged like this:
> > 
> > # grep -w init_task /proc/kallsyms
> > 000003ffe13e9400 D init_task
> > # grep -w _stext /proc/kallsyms
> > 000003ffe0000000 T _stext
> > 
> > 0x3ffe13e9400 - 0x3ffe0000000 == 0x13e9400
> > 
> > # eu-readelf -s vmlinux | grep -w _stext
> > 178112: 0000000000100000      0 NOTYPE  GLOBAL DEFAULT        1 _stext
> > 
> > 0x13e9400 + 0x100000 == 0x14e9400
> > 
> > # eu-readelf -s vmlinux | grep -w init_task
> >   498: 0000000000000000      0 FILE    LOCAL  DEFAULT      ABS init_task.c
> > 182344: 00000000014e9400   8960 OBJECT  GLOBAL DEFAULT       28 init_task
> > 
> > I guess, the above holds true for all architectures.
> > If so, I would suggest consider using that approach.
> > 
> > Having said that, we will try to turn KERNELOFFSET from a synthetic
> > value "Used to compute the page offset" to what drgn expects it to be.
> 
> Thinking about it now, I'm not sure it makes life easier. Because then
> we'll have some old kernels with the current (unexpected) definition of
> KERNELOFFSET and some new kernels with a more standard definition of
> it, but if I read vmcoreinfo, how do I know if the value has the old or
> the new meaning?

The approach I suggested to consider would not use KERNELOFFSET at all.

> Petr T

Thanks!