[PATCH v2 1/1] Calculate offset to field 'init_uts_ns.name'

[PATCH v2 1/1] Calculate offset to field 'init_uts_ns.name'

[Alexander Egorenkov]

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@linux.ibm.com>
---
 makedumpfile.c | 8 ++++++--
 makedumpfile.h | 4 ++++
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/makedumpfile.c b/makedumpfile.c
index 4c4251e..2d62db8 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -1159,7 +1159,7 @@ check_release(void)
 	if (SYMBOL(system_utsname) != NOT_FOUND_SYMBOL) {
 		utsname = SYMBOL(system_utsname);
 	} else if (SYMBOL(init_uts_ns) != NOT_FOUND_SYMBOL) {
-		utsname = SYMBOL(init_uts_ns) + sizeof(int);
+		utsname = SYMBOL(init_uts_ns) + OFFSET(init_uts_ns.name);
 	} else {
 		ERRMSG("Can't get the symbol of system_utsname.\n");
 		return FALSE;
@@ -2077,7 +2077,7 @@ get_str_osrelease_from_vmlinux(void)
 	if (SYMBOL(system_utsname) != NOT_FOUND_SYMBOL) {
 		utsname = SYMBOL(system_utsname);
 	} else if (SYMBOL(init_uts_ns) != NOT_FOUND_SYMBOL) {
-		utsname = SYMBOL(init_uts_ns) + sizeof(int);
+		utsname = SYMBOL(init_uts_ns) + OFFSET(init_uts_ns.name);
 	} else {
 		ERRMSG("Can't get the symbol of system_utsname.\n");
 		return FALSE;
@@ -2285,6 +2285,8 @@ write_vmcoreinfo_data(void)
 	WRITE_MEMBER_OFFSET("mmu_psize_def.shift", mmu_psize_def.shift);
 	WRITE_MEMBER_OFFSET("cpu_spec.mmu_features", cpu_spec.mmu_features);
 
+	WRITE_MEMBER_OFFSET("init_uts_ns.name", init_uts_ns.name);
+
 	if (SYMBOL(node_data) != NOT_FOUND_SYMBOL)
 		WRITE_ARRAY_LENGTH("node_data", node_data);
 	if (SYMBOL(pgdat_list) != NOT_FOUND_SYMBOL)
@@ -2697,6 +2699,8 @@ read_vmcoreinfo(void)
 		READ_MEMBER_OFFSET("log.text_len", printk_log.text_len);
 	}
 
+	READ_MEMBER_OFFSET("init_uts_ns.name", init_uts_ns.name);
+
 	READ_ARRAY_LENGTH("node_data", node_data);
 	READ_ARRAY_LENGTH("pgdat_list", pgdat_list);
 	READ_ARRAY_LENGTH("mem_section", mem_section);
diff --git a/makedumpfile.h b/makedumpfile.h
index 03fb4ce..7d8c54d 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -1880,6 +1880,10 @@ struct offset_table {
 	struct cpu_spec_s {
 		long	mmu_features;
 	} cpu_spec;
+
+	struct init_uts_ns_s {
+		long	name;
+	} init_uts_ns;
 };
 
 /*
-- 
2.26.2


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

RE: [PATCH v2 1/1] Calculate offset to field 'init_uts_ns.name'

[HAGIO KAZUHITO(萩尾 一仁)]

Hi Alexander,

-----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.

Thank you for catching this and the patch.

but do you know the kernel patch corresponding to this patch, i.e. adds
the OFFSET(init_uts_ns.name) (strictly, OFFSET(uts_namespace.name) probably)
entry to vmcoreinfo?  The makedumpfile usually just read it from vmcore,
so cannot calculate without debug info in vmlinux.

If it has not been posted yet, we need to do.  The best situation is
that the patch is merged into linux-next first and then merged into
mainline together with the commit 9a56493f6942.

Is it possible for you?  otherwise, anyone or I might try.

Thanks,
Kazu

> 
> Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
> ---
>  makedumpfile.c | 8 ++++++--
>  makedumpfile.h | 4 ++++
>  2 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/makedumpfile.c b/makedumpfile.c
> index 4c4251e..2d62db8 100644
> --- a/makedumpfile.c
> +++ b/makedumpfile.c
> @@ -1159,7 +1159,7 @@ check_release(void)
>  	if (SYMBOL(system_utsname) != NOT_FOUND_SYMBOL) {
>  		utsname = SYMBOL(system_utsname);
>  	} else if (SYMBOL(init_uts_ns) != NOT_FOUND_SYMBOL) {
> -		utsname = SYMBOL(init_uts_ns) + sizeof(int);
> +		utsname = SYMBOL(init_uts_ns) + OFFSET(init_uts_ns.name);
>  	} else {
>  		ERRMSG("Can't get the symbol of system_utsname.\n");
>  		return FALSE;
> @@ -2077,7 +2077,7 @@ get_str_osrelease_from_vmlinux(void)
>  	if (SYMBOL(system_utsname) != NOT_FOUND_SYMBOL) {
>  		utsname = SYMBOL(system_utsname);
>  	} else if (SYMBOL(init_uts_ns) != NOT_FOUND_SYMBOL) {
> -		utsname = SYMBOL(init_uts_ns) + sizeof(int);
> +		utsname = SYMBOL(init_uts_ns) + OFFSET(init_uts_ns.name);
>  	} else {
>  		ERRMSG("Can't get the symbol of system_utsname.\n");
>  		return FALSE;
> @@ -2285,6 +2285,8 @@ write_vmcoreinfo_data(void)
>  	WRITE_MEMBER_OFFSET("mmu_psize_def.shift", mmu_psize_def.shift);
>  	WRITE_MEMBER_OFFSET("cpu_spec.mmu_features", cpu_spec.mmu_features);
> 
> +	WRITE_MEMBER_OFFSET("init_uts_ns.name", init_uts_ns.name);
> +
>  	if (SYMBOL(node_data) != NOT_FOUND_SYMBOL)
>  		WRITE_ARRAY_LENGTH("node_data", node_data);
>  	if (SYMBOL(pgdat_list) != NOT_FOUND_SYMBOL)
> @@ -2697,6 +2699,8 @@ read_vmcoreinfo(void)
>  		READ_MEMBER_OFFSET("log.text_len", printk_log.text_len);
>  	}
> 
> +	READ_MEMBER_OFFSET("init_uts_ns.name", init_uts_ns.name);
> +
>  	READ_ARRAY_LENGTH("node_data", node_data);
>  	READ_ARRAY_LENGTH("pgdat_list", pgdat_list);
>  	READ_ARRAY_LENGTH("mem_section", mem_section);
> diff --git a/makedumpfile.h b/makedumpfile.h
> index 03fb4ce..7d8c54d 100644
> --- a/makedumpfile.h
> +++ b/makedumpfile.h
> @@ -1880,6 +1880,10 @@ struct offset_table {
>  	struct cpu_spec_s {
>  		long	mmu_features;
>  	} cpu_spec;
> +
> +	struct init_uts_ns_s {
> +		long	name;
> +	} init_uts_ns;
>  };
> 
>  /*
> --
> 2.26.2
> 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

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

RE: [PATCH v2 1/1] Calculate offset to field 'init_uts_ns.name'

[Alexander Egorenkov]

HAGIO KAZUHITO(萩尾　一仁)	<k-hagio-ab@nec.com> writes:


> Thank you for catching this and the patch.
>
> but do you know the kernel patch corresponding to this patch, i.e. adds
> the OFFSET(init_uts_ns.name) (strictly, OFFSET(uts_namespace.name) probably)
> entry to vmcoreinfo?  The makedumpfile usually just read it from vmcore,
> so cannot calculate without debug info in vmlinux.
>
> If it has not been posted yet, we need to do.  The best situation is
> that the patch is merged into linux-next first and then merged into
> mainline together with the commit 9a56493f6942.
>
> Is it possible for you?  otherwise, anyone or I might try.
>
> Thanks,
> Kazu
>

Hi Kazu,

sorry, i'm new to makedumpfile and apparently still not understanding
everything correctly. I checked the *linux-next* repo and couldn't find
anything which adds *init_uts_ns.name*. I only see

	VMCOREINFO_OSRELEASE(init_uts_ns.name.release);

	VMCOREINFO_SYMBOL(init_uts_ns);

I checked kernel/crash_core.c, this is the right place to check, right ?
But my fix seems to work with a crash dump from linux-next.

Thanks
Regards
Alex


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

RE: [PATCH v2 1/1] Calculate offset to field 'init_uts_ns.name'

[Alexander Egorenkov]

HAGIO KAZUHITO(萩尾　一仁)	<k-hagio-ab@nec.com> writes:

>
> Thank you for catching this and the patch.
>
> but do you know the kernel patch corresponding to this patch, i.e. adds
> the OFFSET(init_uts_ns.name) (strictly, OFFSET(uts_namespace.name) probably)
> entry to vmcoreinfo?  The makedumpfile usually just read it from vmcore,
> so cannot calculate without debug info in vmlinux.
>
> If it has not been posted yet, we need to do.  The best situation is
> that the patch is merged into linux-next first and then merged into
> mainline together with the commit 9a56493f6942.
>
> Is it possible for you?  otherwise, anyone or I might try.
>

Hi Kazu,

my patch doesn't really work :( The offset from 'init_uts_ns' to 'name'
has changed from 4 to 0 but how do you handle that in makedumpfile w/o
first knowing what kernel version that is. It is a chicken-and-egg
problem. Not sure how to solve it. The Linux kernel doesn't provide
the symbol 'init_ns_ns.name' as i initially thought and ,therefore,
i based my patch on a wrong assumption. It would be nice if kernel just
provided a symbol for 'init_uts_ns.name' instead of 'init_uts_ns' which
might change anytime.

Regards
Alex

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

RE: [PATCH v2 1/1] Calculate offset to field 'init_uts_ns.name'

[HAGIO KAZUHITO(萩尾 一仁)]

Hi Alex,

-----Original Message-----
> HAGIO KAZUHITO(萩尾　一仁)	<k-hagio-ab@nec.com> writes:
> 
> >
> > Thank you for catching this and the patch.
> >
> > but do you know the kernel patch corresponding to this patch, i.e. adds
> > the OFFSET(init_uts_ns.name) (strictly, OFFSET(uts_namespace.name) probably)
> > entry to vmcoreinfo?  The makedumpfile usually just read it from vmcore,
> > so cannot calculate without debug info in vmlinux.
> >
> > If it has not been posted yet, we need to do.  The best situation is
> > that the patch is merged into linux-next first and then merged into
> > mainline together with the commit 9a56493f6942.
> >
> > Is it possible for you?  otherwise, anyone or I might try.
> >
> 
> Hi Kazu,
> 
> my patch doesn't really work :( The offset from 'init_uts_ns' to 'name'
> has changed from 4 to 0 but how do you handle that in makedumpfile w/o
> first knowing what kernel version that is. It is a chicken-and-egg
> problem. Not sure how to solve it. The Linux kernel doesn't provide
> the symbol 'init_ns_ns.name' as i initially thought and ,therefore,
> i based my patch on a wrong assumption. It would be nice if kernel just
> provided a symbol for 'init_uts_ns.name' instead of 'init_uts_ns' which
> might change anytime.

Yes, I think there are two options to solve it:

(1) Replace VMCOREINFO_SYMBOL(init_uts_ns) with VMCOREINFO_SYMBOL(init_uts_ns.name)
in vmcoreinfo (kernel/crash_core.c, which you checked)

and makedumpfile side:

  if (SYMBOL(init_uts_ns.name) != NOT_FOUND_SYMBOL)
    utsname = SYMBOL(init_uts_ns.name)
  else if (SYMBOL(init_uts_ns) != NOT_FOUND_SYMBOL)
    utsname = SYMBOL(init_uts_ns) + sizeof(int)
  ...

According to the definition of the VMCOREINFO_SYMBO() macro, this will
work file, but I've not seen such a usage (specifies a member of struct)
and it would be better to avoid.  And we will have to have a bit tricky
part in makedumpfile source for "-x vmlinux" option support.

Also I'm not sure whether there are other users than makedumpfile depending
on the current SYMBOL(init_uts_ns) and whether we can change it.
(probably no other user, though..)

(2) Append VMCOREINFO_OFFSET(uts_namespace, name) to vmcoreinfo.

and makedumpfile side:

  if (SYMBOL(init_uts_ns) != NOT_FOUND_SYMBOL) {
    if (OFFSET(uts_namespace.name) != NOT_FOUND_STRUCTURE)
      utsname = SYMBOL(init_uts_ns) + OFFSET(uts_namespace.name)
    else
      utsname = SYMBOL(init_uts_ns) + sizeof(int)
  ...

The VMCOREINFO_OFFSET() macro takes a struct name and its member name.
This option doesn't change the current SYMBOL(init_uts_ns).

So personally I would prefer (2) rather than (1).
If you can post a kernel patch, please cc this kexec list.

Thanks,
Kazu

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