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

[Omar Sandoval <osandov@osandov.com>]

On Wed, Jul 10, 2024 at 10:53:11AM +0200, Alexander Gordeev wrote:
> 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.

Hi,

Unfortunately, using kallsyms isn't feasible for a few reasons:

1) /proc/kallsyms is not available when debugging a core dump.
2) As you pointed out, /proc/kallsyms is not necessarily enabled
   together with /proc/kcore.
3) Reading /proc/kallsyms is slow. On my system, drgn starts up in about
   250ms, and reading /proc/kallsyms takes about 110 ms.  This would
   slow down startup too much.

drgn intentionally avoids kallsyms for these reasons. (There is one
corner case on old < 4.11 kernels where we need kallsyms, but that will
go away eventually.)

I'd be really grateful if KERNELOFFSET was always the difference between
addresses in the kernel image and in memory like it is on other
architectures, or even if there was another, s390x-specific field in
vmcoreinfo for that.

Thanks,
Omar