On Thu, 1 Oct 2020 00:38:23 +0000
HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab(a)nec.com> wrote:
Hi Alex,
sorry for the delayed response.
I misunderstood at first glance and have waited for the kernel patch
adding the vmcoreinfo entry you posted, but I just found no need to
wait for it with respect to crash.
-----Original Message-----
> The offset has changed in linux-next (v5.9.0) from 4 to 0 because
> there is no more 'kref' member variable at the beginning of
'init_uts_ns'.
> The change was introduced with commit 9a56493f6942c0e2df1579986128721da96e00d8.
> To handle both cases correctly, calculate the offset at run time instead.
>
> Signed-off-by: Alexander Egorenkov <egorenar(a)linux.ibm.com>
> ---
> kernel.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel.c b/kernel.c
> index 21bd1eb..13942b9 100644
> --- a/kernel.c
> +++ b/kernel.c
> @@ -237,7 +237,7 @@ kernel_init()
> sizeof(struct new_utsname), "system_utsname",
> RETURN_ON_ERROR);
> else if (symbol_exists("init_uts_ns"))
> - readmem(symbol_value("init_uts_ns") + sizeof(int),
> + readmem(symbol_value("init_uts_ns") +
ANON_MEMBER_OFFSET("uts_namespace","name"),
When we get an offset from vmlinux, usually we introduce a member to
struct offset_table (at the tail of it) and populate it with MEMBER_OFFSET_INIT()
macro so that we can reuse it and dump it with dump_offset_table() function.
Can you please update so?
For reference:
https://www.redhat.com/archives/crash-utility/2020-August/msg00052.html
and fyi, crash doesn't use the vmcoreinfo entry OFFSET(uts_namespace.name)
with respect to this case.
FYI here's how libkdumpfile deals with the issue:
https://github.com/ptesarik/libkdumpfile/blob/tip/src/kdumpfile/open.c#L129
Essentially, we can only handle Linux kernel dumps anyway, so sysname
is always set to "Linux". You can search for this "magic" string, and
then you have the address of init_uts_ns.name.sysname. Calculating t
address of init_uts_ns.name is then trivial.
Just my two cents,
Petr T