[PATCH v2] vmcoreinfo: make hwerr_data visible for debugging

[PATCH v2] vmcoreinfo: make hwerr_data visible for debugging

[Breno Leitao]

If the kernel is compiled with LTO, hwerr_data symbol might be lost, and
vmcoreinfo doesn't have it dumped. This is currently seen in some
production kernels with LTO enabled.

Remove the static qualifier from hwerr_data so that the information is
still preserved when the kernel is built with LTO. Making hwerr_data
a global symbol ensures its debug info survives the LTO link process and
appears in kallsyms. Also document it, so, it doesn't get removed in the
future as suggested by akpm.

Signed-off-by: Breno Leitao <leitao@debian.org>
---
Changes in v2:
- Add a comment to explain why the array is global (akpm)
- Link to v1: https://patch.msgid.link/20260121-fix_vmcoreinfo-v1-1-39e96fab670e@debian.org
---
 kernel/vmcore_info.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/kernel/vmcore_info.c b/kernel/vmcore_info.c
index 22b3205dd4dc5..46198580373a4 100644
--- a/kernel/vmcore_info.c
+++ b/kernel/vmcore_info.c
@@ -36,7 +36,11 @@ struct hwerr_info {
 	time64_t timestamp;
 };
 
-static struct hwerr_info hwerr_data[HWERR_RECOV_MAX];
+/*
+ * The hwerr_data[] array is declared with global scope so that it remains
+ * accessible to vmcoreinfo even when Link Time Optimization (LTO) is enabled.
+ */
+struct hwerr_info hwerr_data[HWERR_RECOV_MAX];
 
 Elf_Word *append_elf_note(Elf_Word *buf, char *name, unsigned int type,
 			  void *data, size_t data_len)

---
base-commit: 053966c344dbd346e71305f530e91ea77916189f
change-id: 20260121-fix_vmcoreinfo-01592f705a77

Best regards,
--  
Breno Leitao <leitao@debian.org>

Re: [PATCH v2] vmcoreinfo: make hwerr_data visible for debugging

[Baoquan He]

On 01/22/26 at 02:39am, Breno Leitao wrote:
> If the kernel is compiled with LTO, hwerr_data symbol might be lost, and
> vmcoreinfo doesn't have it dumped. This is currently seen in some
> production kernels with LTO enabled.
> 
> Remove the static qualifier from hwerr_data so that the information is
> still preserved when the kernel is built with LTO. Making hwerr_data
> a global symbol ensures its debug info survives the LTO link process and
> appears in kallsyms. Also document it, so, it doesn't get removed in the
> future as suggested by akpm.
> 
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
> Changes in v2:
> - Add a comment to explain why the array is global (akpm)
> - Link to v1: https://patch.msgid.link/20260121-fix_vmcoreinfo-v1-1-39e96fab670e@debian.org
> ---
>  kernel/vmcore_info.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)

LGTM,

Acked-by: Baoquan He <bhe@redhat.com>

BTW, is it worth a 'Fixes' tag?

> 
> diff --git a/kernel/vmcore_info.c b/kernel/vmcore_info.c
> index 22b3205dd4dc5..46198580373a4 100644
> --- a/kernel/vmcore_info.c
> +++ b/kernel/vmcore_info.c
> @@ -36,7 +36,11 @@ struct hwerr_info {
>  	time64_t timestamp;
>  };
>  
> -static struct hwerr_info hwerr_data[HWERR_RECOV_MAX];
> +/*
> + * The hwerr_data[] array is declared with global scope so that it remains
> + * accessible to vmcoreinfo even when Link Time Optimization (LTO) is enabled.
> + */
> +struct hwerr_info hwerr_data[HWERR_RECOV_MAX];
>  
>  Elf_Word *append_elf_note(Elf_Word *buf, char *name, unsigned int type,
>  			  void *data, size_t data_len)
> 
> ---
> base-commit: 053966c344dbd346e71305f530e91ea77916189f
> change-id: 20260121-fix_vmcoreinfo-01592f705a77
> 
> Best regards,
> --  
> Breno Leitao <leitao@debian.org>
> 

Re: [PATCH v2] vmcoreinfo: make hwerr_data visible for debugging

[Breno Leitao]

Hello Baoquan,

On Fri, Jan 23, 2026 at 08:19:40AM +0800, Baoquan He wrote:
> On 01/22/26 at 02:39am, Breno Leitao wrote:
> > If the kernel is compiled with LTO, hwerr_data symbol might be lost, and
> > vmcoreinfo doesn't have it dumped. This is currently seen in some
> > production kernels with LTO enabled.
> > 
> > Remove the static qualifier from hwerr_data so that the information is
> > still preserved when the kernel is built with LTO. Making hwerr_data
> > a global symbol ensures its debug info survives the LTO link process and
> > appears in kallsyms. Also document it, so, it doesn't get removed in the
> > future as suggested by akpm.
> > 
> > Signed-off-by: Breno Leitao <leitao@debian.org>
> > ---
> > Changes in v2:
> > - Add a comment to explain why the array is global (akpm)
> > - Link to v1: https://patch.msgid.link/20260121-fix_vmcoreinfo-v1-1-39e96fab670e@debian.org
> > ---
> >  kernel/vmcore_info.c | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> LGTM,
> 
> Acked-by: Baoquan He <bhe@redhat.com>
> 
> BTW, is it worth a 'Fixes' tag?

I am not sure, but, if we prefer to, this is the correct tag:

Fixes: 3fa805c37dd4d ("vmcoreinfo: track and log recoverable hardware errors")

Thanks for the review,
--breno

Re: [PATCH v2] vmcoreinfo: make hwerr_data visible for debugging

[Andrew Morton]

On Fri, 23 Jan 2026 01:24:17 -0800 Breno Leitao <leitao@debian.org> wrote:

> Hello Baoquan,
> 
> On Fri, Jan 23, 2026 at 08:19:40AM +0800, Baoquan He wrote:
> > On 01/22/26 at 02:39am, Breno Leitao wrote:
> > > If the kernel is compiled with LTO, hwerr_data symbol might be lost, and
> > > vmcoreinfo doesn't have it dumped. This is currently seen in some
> > > production kernels with LTO enabled.
> > > 
> > > Remove the static qualifier from hwerr_data so that the information is
> > > still preserved when the kernel is built with LTO. Making hwerr_data
> > > a global symbol ensures its debug info survives the LTO link process and
> > > appears in kallsyms. Also document it, so, it doesn't get removed in the
> > > future as suggested by akpm.
> > > 
> > > Signed-off-by: Breno Leitao <leitao@debian.org>
> > > ---
> > > Changes in v2:
> > > - Add a comment to explain why the array is global (akpm)
> > > - Link to v1: https://patch.msgid.link/20260121-fix_vmcoreinfo-v1-1-39e96fab670e@debian.org
> > > ---
> > >  kernel/vmcore_info.c | 6 +++++-
> > >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > LGTM,
> > 
> > Acked-by: Baoquan He <bhe@redhat.com>
> > 
> > BTW, is it worth a 'Fixes' tag?
> 
> I am not sure, but, if we prefer to, this is the correct tag:
> 
> Fixes: 3fa805c37dd4d ("vmcoreinfo: track and log recoverable hardware errors")

3fa805c37dd4d was added in 6.19-rc1, so this patch is a fixup against
this rc series.  So yes, it should go into 6.19-rcX also.

I hadn't noticed the timing here so thanks both for pointing it out.

Re: [PATCH v2] vmcoreinfo: make hwerr_data visible for debugging

[Baoquan He]

On 01/23/26 at 04:49pm, Andrew Morton wrote:
> On Fri, 23 Jan 2026 01:24:17 -0800 Breno Leitao <leitao@debian.org> wrote:
> 
> > Hello Baoquan,
> > 
> > On Fri, Jan 23, 2026 at 08:19:40AM +0800, Baoquan He wrote:
> > > On 01/22/26 at 02:39am, Breno Leitao wrote:
> > > > If the kernel is compiled with LTO, hwerr_data symbol might be lost, and
> > > > vmcoreinfo doesn't have it dumped. This is currently seen in some
> > > > production kernels with LTO enabled.
> > > > 
> > > > Remove the static qualifier from hwerr_data so that the information is
> > > > still preserved when the kernel is built with LTO. Making hwerr_data
> > > > a global symbol ensures its debug info survives the LTO link process and
> > > > appears in kallsyms. Also document it, so, it doesn't get removed in the
> > > > future as suggested by akpm.
> > > > 
> > > > Signed-off-by: Breno Leitao <leitao@debian.org>
> > > > ---
> > > > Changes in v2:
> > > > - Add a comment to explain why the array is global (akpm)
> > > > - Link to v1: https://patch.msgid.link/20260121-fix_vmcoreinfo-v1-1-39e96fab670e@debian.org
> > > > ---
> > > >  kernel/vmcore_info.c | 6 +++++-
> > > >  1 file changed, 5 insertions(+), 1 deletion(-)
> > > 
> > > LGTM,
> > > 
> > > Acked-by: Baoquan He <bhe@redhat.com>
> > > 
> > > BTW, is it worth a 'Fixes' tag?
> > 
> > I am not sure, but, if we prefer to, this is the correct tag:
> > 
> > Fixes: 3fa805c37dd4d ("vmcoreinfo: track and log recoverable hardware errors")
> 
> 3fa805c37dd4d was added in 6.19-rc1, so this patch is a fixup against
> this rc series.  So yes, it should go into 6.19-rcX also.

Ah, then no need. thanks.