This patch declares percpu variables in __seg_gs/__seg_fs named AS
and keeps them named AS qualified until they are dereferenced with
percpu accessor. This approach enables various compiler check
for cross-namespace variable assignments.
Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Acked-by: Nadav Amit <nadav.amit@gmail.com>
Cc: Dennis Zhou <dennis@kernel.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Christoph Lameter <cl@linux.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
---
arch/x86/include/asm/percpu.h | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h
index 27f668660abe..474d648bca9a 100644
--- a/arch/x86/include/asm/percpu.h
+++ b/arch/x86/include/asm/percpu.h
@@ -95,9 +95,18 @@
#endif /* CONFIG_SMP */
-#define __my_cpu_type(var) typeof(var) __percpu_seg_override
-#define __my_cpu_ptr(ptr) (__my_cpu_type(*(ptr))*)(__force uintptr_t)(ptr)
-#define __my_cpu_var(var) (*__my_cpu_ptr(&(var)))
+#if defined(CONFIG_USE_X86_SEG_SUPPORT) && defined(USE_TYPEOF_UNQUAL)
+# define __my_cpu_type(var) typeof(var)
+# define __my_cpu_ptr(ptr) (ptr)
+# define __my_cpu_var(var) (var)
+
+# define __percpu_qual __percpu_seg_override
+#else
+# define __my_cpu_type(var) typeof(var) __percpu_seg_override
+# define __my_cpu_ptr(ptr) (__my_cpu_type(*(ptr))*)(__force uintptr_t)(ptr)
+# define __my_cpu_var(var) (*__my_cpu_ptr(&(var)))
+#endif
+
#define __percpu_arg(x) __percpu_prefix "%" #x
#define __force_percpu_arg(x) __force_percpu_prefix "%" #x
--
2.42.0On 27. 01. 25, 17:05, Uros Bizjak wrote: > This patch declares percpu variables in __seg_gs/__seg_fs named AS > and keeps them named AS qualified until they are dereferenced with > percpu accessor. This approach enables various compiler check > for cross-namespace variable assignments. So this causes modpost to fail to version some symbols: > WARNING: modpost: EXPORT symbol "xen_vcpu_id" [vmlinux] version generation failed, symbol will not be versioned. > Is "xen_vcpu_id" prototyped in <asm/asm-prototypes.h>? > WARNING: modpost: EXPORT symbol "irq_stat" [vmlinux] version generation failed, symbol will not be versioned. > Is "irq_stat" prototyped in <asm/asm-prototypes.h>? > WARNING: modpost: EXPORT symbol "fred_rsp0" [vmlinux] version generation failed, symbol will not be versioned. > Is "fred_rsp0" prototyped in <asm/asm-prototypes.h>? > WARNING: modpost: EXPORT symbol "cpu_dr7" [vmlinux] version generation failed, symbol will not be versioned. > Is "cpu_dr7" prototyped in <asm/asm-prototypes.h>? > WARNING: modpost: EXPORT symbol "cpu_tss_rw" [vmlinux] version generation failed, symbol will not be versioned. > Is "cpu_tss_rw" prototyped in <asm/asm-prototypes.h>? > WARNING: modpost: EXPORT symbol "__tss_limit_invalid" [vmlinux] version generation failed, symbol will not be versioned. > Is "__tss_limit_invalid" prototyped in <asm/asm-prototypes.h>? > WARNING: modpost: EXPORT symbol "irq_fpu_usable" [vmlinux] version generation failed, symbol will not be versioned. > Is "irq_fpu_usable" prototyped in <asm/asm-prototypes.h>? > WARNING: modpost: EXPORT symbol "cpu_info" [vmlinux] version generation failed, symbol will not be versioned. > Is "cpu_info" prototyped in <asm/asm-prototypes.h>? > WARNING: modpost: EXPORT symbol "gdt_page" [vmlinux] version generation failed, symbol will not be versioned. > Is "gdt_page" prototyped in <asm/asm-prototypes.h>? > ... That happens both with 6.15-rc1 and today's -next. Ideas? Config: https://github.com/SUSE/kernel-source/blob/master/config/x86_64/default It is enough to: make CC='ccache gcc-14' O=../our -j160 vmlinux to see the above. > Signed-off-by: Uros Bizjak <ubizjak@gmail.com> > Acked-by: Nadav Amit <nadav.amit@gmail.com> > Cc: Dennis Zhou <dennis@kernel.org> > Cc: Tejun Heo <tj@kernel.org> > Cc: Christoph Lameter <cl@linux.com> > Cc: Thomas Gleixner <tglx@linutronix.de> > Cc: Ingo Molnar <mingo@kernel.org> > Cc: Borislav Petkov <bp@alien8.de> > Cc: Dave Hansen <dave.hansen@linux.intel.com> > Cc: "H. Peter Anvin" <hpa@zytor.com> > Cc: Linus Torvalds <torvalds@linux-foundation.org> > Cc: Andy Lutomirski <luto@kernel.org> > Cc: Brian Gerst <brgerst@gmail.com> > Cc: Peter Zijlstra <peterz@infradead.org> > --- > arch/x86/include/asm/percpu.h | 15 ++++++++++++--- > 1 file changed, 12 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h > index 27f668660abe..474d648bca9a 100644 > --- a/arch/x86/include/asm/percpu.h > +++ b/arch/x86/include/asm/percpu.h > @@ -95,9 +95,18 @@ > > #endif /* CONFIG_SMP */ > > -#define __my_cpu_type(var) typeof(var) __percpu_seg_override > -#define __my_cpu_ptr(ptr) (__my_cpu_type(*(ptr))*)(__force uintptr_t)(ptr) > -#define __my_cpu_var(var) (*__my_cpu_ptr(&(var))) > +#if defined(CONFIG_USE_X86_SEG_SUPPORT) && defined(USE_TYPEOF_UNQUAL) > +# define __my_cpu_type(var) typeof(var) > +# define __my_cpu_ptr(ptr) (ptr) > +# define __my_cpu_var(var) (var) > + > +# define __percpu_qual __percpu_seg_override > +#else > +# define __my_cpu_type(var) typeof(var) __percpu_seg_override > +# define __my_cpu_ptr(ptr) (__my_cpu_type(*(ptr))*)(__force uintptr_t)(ptr) > +# define __my_cpu_var(var) (*__my_cpu_ptr(&(var))) > +#endif > + > #define __percpu_arg(x) __percpu_prefix "%" #x > #define __force_percpu_arg(x) __force_percpu_prefix "%" #x thanks, -- js suse labs
On Wed, Apr 9, 2025 at 1:07 PM Jiri Slaby <jirislaby@kernel.org> wrote: > > On 27. 01. 25, 17:05, Uros Bizjak wrote: > > This patch declares percpu variables in __seg_gs/__seg_fs named AS > > and keeps them named AS qualified until they are dereferenced with > > percpu accessor. This approach enables various compiler check > > for cross-namespace variable assignments. > > So this causes modpost to fail to version some symbols: > > > WARNING: modpost: EXPORT symbol "xen_vcpu_id" [vmlinux] version generation failed, symbol will not be versioned. > > Is "xen_vcpu_id" prototyped in <asm/asm-prototypes.h>? > > WARNING: modpost: EXPORT symbol "irq_stat" [vmlinux] version generation failed, symbol will not be versioned. > > Is "irq_stat" prototyped in <asm/asm-prototypes.h>? > > WARNING: modpost: EXPORT symbol "fred_rsp0" [vmlinux] version generation failed, symbol will not be versioned. > > Is "fred_rsp0" prototyped in <asm/asm-prototypes.h>? > > WARNING: modpost: EXPORT symbol "cpu_dr7" [vmlinux] version generation failed, symbol will not be versioned. > > Is "cpu_dr7" prototyped in <asm/asm-prototypes.h>? > > WARNING: modpost: EXPORT symbol "cpu_tss_rw" [vmlinux] version generation failed, symbol will not be versioned. > > Is "cpu_tss_rw" prototyped in <asm/asm-prototypes.h>? > > WARNING: modpost: EXPORT symbol "__tss_limit_invalid" [vmlinux] version generation failed, symbol will not be versioned. > > Is "__tss_limit_invalid" prototyped in <asm/asm-prototypes.h>? > > WARNING: modpost: EXPORT symbol "irq_fpu_usable" [vmlinux] version generation failed, symbol will not be versioned. > > Is "irq_fpu_usable" prototyped in <asm/asm-prototypes.h>? > > WARNING: modpost: EXPORT symbol "cpu_info" [vmlinux] version generation failed, symbol will not be versioned. > > Is "cpu_info" prototyped in <asm/asm-prototypes.h>? > > WARNING: modpost: EXPORT symbol "gdt_page" [vmlinux] version generation failed, symbol will not be versioned. > > Is "gdt_page" prototyped in <asm/asm-prototypes.h>? > > ... > > That happens both with 6.15-rc1 and today's -next. Ideas? https://lore.kernel.org/lkml/20250404102535.705090-1-ubizjak@gmail.com/ Uros.
On April 9, 2025 4:43:27 AM PDT, Uros Bizjak <ubizjak@gmail.com> wrote: >On Wed, Apr 9, 2025 at 1:07 PM Jiri Slaby <jirislaby@kernel.org> wrote: >> >> On 27. 01. 25, 17:05, Uros Bizjak wrote: >> > This patch declares percpu variables in __seg_gs/__seg_fs named AS >> > and keeps them named AS qualified until they are dereferenced with >> > percpu accessor. This approach enables various compiler check >> > for cross-namespace variable assignments. >> >> So this causes modpost to fail to version some symbols: >> >> > WARNING: modpost: EXPORT symbol "xen_vcpu_id" [vmlinux] version generation failed, symbol will not be versioned. >> > Is "xen_vcpu_id" prototyped in <asm/asm-prototypes.h>? >> > WARNING: modpost: EXPORT symbol "irq_stat" [vmlinux] version generation failed, symbol will not be versioned. >> > Is "irq_stat" prototyped in <asm/asm-prototypes.h>? >> > WARNING: modpost: EXPORT symbol "fred_rsp0" [vmlinux] version generation failed, symbol will not be versioned. >> > Is "fred_rsp0" prototyped in <asm/asm-prototypes.h>? >> > WARNING: modpost: EXPORT symbol "cpu_dr7" [vmlinux] version generation failed, symbol will not be versioned. >> > Is "cpu_dr7" prototyped in <asm/asm-prototypes.h>? >> > WARNING: modpost: EXPORT symbol "cpu_tss_rw" [vmlinux] version generation failed, symbol will not be versioned. >> > Is "cpu_tss_rw" prototyped in <asm/asm-prototypes.h>? >> > WARNING: modpost: EXPORT symbol "__tss_limit_invalid" [vmlinux] version generation failed, symbol will not be versioned. >> > Is "__tss_limit_invalid" prototyped in <asm/asm-prototypes.h>? >> > WARNING: modpost: EXPORT symbol "irq_fpu_usable" [vmlinux] version generation failed, symbol will not be versioned. >> > Is "irq_fpu_usable" prototyped in <asm/asm-prototypes.h>? >> > WARNING: modpost: EXPORT symbol "cpu_info" [vmlinux] version generation failed, symbol will not be versioned. >> > Is "cpu_info" prototyped in <asm/asm-prototypes.h>? >> > WARNING: modpost: EXPORT symbol "gdt_page" [vmlinux] version generation failed, symbol will not be versioned. >> > Is "gdt_page" prototyped in <asm/asm-prototypes.h>? >> > ... >> >> That happens both with 6.15-rc1 and today's -next. Ideas? > >https://lore.kernel.org/lkml/20250404102535.705090-1-ubizjak@gmail.com/ > >Uros. > A lot of those seem to be things that definitely shouldn't be expected...
On Wed, Apr 9, 2025 at 5:09 PM H. Peter Anvin <hpa@zytor.com> wrote:
>
> On April 9, 2025 4:43:27 AM PDT, Uros Bizjak <ubizjak@gmail.com> wrote:
> >On Wed, Apr 9, 2025 at 1:07 PM Jiri Slaby <jirislaby@kernel.org> wrote:
> >>
> >> On 27. 01. 25, 17:05, Uros Bizjak wrote:
> >> > This patch declares percpu variables in __seg_gs/__seg_fs named AS
> >> > and keeps them named AS qualified until they are dereferenced with
> >> > percpu accessor. This approach enables various compiler check
> >> > for cross-namespace variable assignments.
> >>
> >> So this causes modpost to fail to version some symbols:
> >>
> >> > WARNING: modpost: EXPORT symbol "xen_vcpu_id" [vmlinux] version generation failed, symbol will not be versioned.
> >> > Is "xen_vcpu_id" prototyped in <asm/asm-prototypes.h>?
> >> > WARNING: modpost: EXPORT symbol "irq_stat" [vmlinux] version generation failed, symbol will not be versioned.
> >> > Is "irq_stat" prototyped in <asm/asm-prototypes.h>?
> >> > WARNING: modpost: EXPORT symbol "fred_rsp0" [vmlinux] version generation failed, symbol will not be versioned.
> >> > Is "fred_rsp0" prototyped in <asm/asm-prototypes.h>?
> >> > WARNING: modpost: EXPORT symbol "cpu_dr7" [vmlinux] version generation failed, symbol will not be versioned.
> >> > Is "cpu_dr7" prototyped in <asm/asm-prototypes.h>?
> >> > WARNING: modpost: EXPORT symbol "cpu_tss_rw" [vmlinux] version generation failed, symbol will not be versioned.
> >> > Is "cpu_tss_rw" prototyped in <asm/asm-prototypes.h>?
> >> > WARNING: modpost: EXPORT symbol "__tss_limit_invalid" [vmlinux] version generation failed, symbol will not be versioned.
> >> > Is "__tss_limit_invalid" prototyped in <asm/asm-prototypes.h>?
> >> > WARNING: modpost: EXPORT symbol "irq_fpu_usable" [vmlinux] version generation failed, symbol will not be versioned.
> >> > Is "irq_fpu_usable" prototyped in <asm/asm-prototypes.h>?
> >> > WARNING: modpost: EXPORT symbol "cpu_info" [vmlinux] version generation failed, symbol will not be versioned.
> >> > Is "cpu_info" prototyped in <asm/asm-prototypes.h>?
> >> > WARNING: modpost: EXPORT symbol "gdt_page" [vmlinux] version generation failed, symbol will not be versioned.
> >> > Is "gdt_page" prototyped in <asm/asm-prototypes.h>?
> >> > ...
> >>
> >> That happens both with 6.15-rc1 and today's -next. Ideas?
> >
> >https://lore.kernel.org/lkml/20250404102535.705090-1-ubizjak@gmail.com/
> A lot of those seem to be things that definitely shouldn't be expected...
These symbols are just declared with an extra __seg_gs that genksyms
doesn't understand, e.g.:
extern __seg_gs __attribute__((section(".data..percpu" "..hot.."
"this_cpu_off"))) __typeof__(unsigned long) this_cpu_off;
The workaround falls back when __GENKSYMS__ is defined to:
extern __attribute__((section(".data..percpu" "..hot.."
"this_cpu_off"))) __typeof__(unsigned long) this_cpu_off;
which is what genksyms processes without problems.
Uros.
On 27. 01. 25, 17:05, Uros Bizjak wrote:
> This patch declares percpu variables in __seg_gs/__seg_fs named AS
> and keeps them named AS qualified until they are dereferenced with
> percpu accessor. This approach enables various compiler check
> for cross-namespace variable assignments.
>
> Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
> Acked-by: Nadav Amit <nadav.amit@gmail.com>
> Cc: Dennis Zhou <dennis@kernel.org>
> Cc: Tejun Heo <tj@kernel.org>
> Cc: Christoph Lameter <cl@linux.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Brian Gerst <brgerst@gmail.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> ---
> arch/x86/include/asm/percpu.h | 15 ++++++++++++---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h
> index 27f668660abe..474d648bca9a 100644
> --- a/arch/x86/include/asm/percpu.h
> +++ b/arch/x86/include/asm/percpu.h
> @@ -95,9 +95,18 @@
>
> #endif /* CONFIG_SMP */
>
> -#define __my_cpu_type(var) typeof(var) __percpu_seg_override
> -#define __my_cpu_ptr(ptr) (__my_cpu_type(*(ptr))*)(__force uintptr_t)(ptr)
> -#define __my_cpu_var(var) (*__my_cpu_ptr(&(var)))
> +#if defined(CONFIG_USE_X86_SEG_SUPPORT) && defined(USE_TYPEOF_UNQUAL)
> +# define __my_cpu_type(var) typeof(var)
> +# define __my_cpu_ptr(ptr) (ptr)
> +# define __my_cpu_var(var) (var)
> +
> +# define __percpu_qual __percpu_seg_override
> +#else
> +# define __my_cpu_type(var) typeof(var) __percpu_seg_override
> +# define __my_cpu_ptr(ptr) (__my_cpu_type(*(ptr))*)(__force uintptr_t)(ptr)
> +# define __my_cpu_var(var) (*__my_cpu_ptr(&(var)))
> +#endif
> +
Another issue with this is this causes all modules in 6.15 are 2-4 times
(compressed size) bigger:
$ ll /usr/lib/modules/*-[0-9]-default/kernel/drivers/atm/atmtcp.ko.zst
> -rw-r--r--. 1 root root 10325 May 13 11:49
/usr/lib/modules/6.14.6-2-default/kernel/drivers/atm/atmtcp.ko.zst
> -rw-r--r--. 1 root root 39677 Jun 2 09:13
/usr/lib/modules/6.15.0-1-default/kernel/drivers/atm/atmtcp.ko.zst
It's due to larger .BTF section:
.BTF PROGBITS 0000000000000000 [-00003080-]
[- 00000000000011a8-] {+00003100+}
{+ 0000000000012cf8+} 0000000000000000 0 0 1
There are a lot of new BTF types defined in each module like:
+attribute_group STRUCT
+backing_dev_info STRUCT
+bdi_writeback STRUCT
+bin_attribute STRUCT
+bio_end_io_t TYPEDEF
+bio_list STRUCT
+bio_set STRUCT
+bio STRUCT
+bio_vec STRUCT
Reverting this gives me back to normal sizes.
Any ideas?
FTR downstream report:
https://bugzilla.suse.com/show_bug.cgi?id=1244135
thanks,
--
js
suse labs
On 6/5/25 07:27, Jiri Slaby wrote: > Reverting this gives me back to normal sizes. > > Any ideas? I don't see any reason not to revert it. The benefits weren't exactly clear from the changelogs or cover letter. Enabling "various compiler checks" doesn't exactly scream that this is critical to end users in some way. The only question is if we revert just this last patch or the whole series. Uros, is there an alternative to reverting?
On Thu, Jun 5, 2025 at 7:15 PM Dave Hansen <dave.hansen@intel.com> wrote: > > On 6/5/25 07:27, Jiri Slaby wrote: > > Reverting this gives me back to normal sizes. > > > > Any ideas? > > I don't see any reason not to revert it. The benefits weren't exactly > clear from the changelogs or cover letter. Enabling "various compiler > checks" doesn't exactly scream that this is critical to end users in > some way. > > The only question is if we revert just this last patch or the whole series. > > Uros, is there an alternative to reverting? This functionality can easily be disabled in include/linux/compiler.h by not defining USE_TYPEOF_UNQUAL: #if CC_HAS_TYPEOF_UNQUAL && !defined(__CHECKER__) # define USE_TYPEOF_UNQUAL 1 #endif (support for typeof_unqual keyword is required to handle __seg_gs qualifiers), but ... ... the issue is reportedly fixed, please see [1], and ... ... you will disable much sought of feature, just ask tglx (and please read his rant at [2]): --q-- If the compiler people would have provided a way to utilize the anyway non-standard name space support in a useful way, I could have spared the time to bang my head agaist the wall simply because this would have failed to build in the first place long ago. That just makes me sad. --/q-- [1] https://lore.kernel.org/bpf/20250429161042.2069678-1-alan.maguire@oracle.com/ [2] https://lore.kernel.org/lkml/20240303235029.555787150@linutronix.de/ Uros.
On 05. 06. 25, 19:31, Uros Bizjak wrote: > On Thu, Jun 5, 2025 at 7:15 PM Dave Hansen <dave.hansen@intel.com> wrote: >> >> On 6/5/25 07:27, Jiri Slaby wrote: >>> Reverting this gives me back to normal sizes. >>> >>> Any ideas? >> >> I don't see any reason not to revert it. The benefits weren't exactly >> clear from the changelogs or cover letter. Enabling "various compiler >> checks" doesn't exactly scream that this is critical to end users in >> some way. >> >> The only question is if we revert just this last patch or the whole series. >> >> Uros, is there an alternative to reverting? > > This functionality can easily be disabled in include/linux/compiler.h > by not defining USE_TYPEOF_UNQUAL: > > #if CC_HAS_TYPEOF_UNQUAL && !defined(__CHECKER__) > # define USE_TYPEOF_UNQUAL 1 > #endif > > (support for typeof_unqual keyword is required to handle __seg_gs > qualifiers), but ... > > ... the issue is reportedly fixed, please see [1], and ... Confirmed, I need a patched userspace (libbpf). > ... you will disable much sought of feature, just ask tglx (and please > read his rant at [2]): Given this is the second time I hit a bug with this, perhaps introduce an EXPERIMENTAL CONFIG option, so that random users can simply disable it if an issue occurs? Without the need of patching random userspace and changing random kernel headers? > --q-- > If the compiler people would have provided a way to utilize the anyway > non-standard name space support in a useful way, I could have spared the > time to bang my head agaist the wall simply because this would have failed > to build in the first place long ago. That just makes me sad. > --/q-- > > [1] https://lore.kernel.org/bpf/20250429161042.2069678-1-alan.maguire@oracle.com/ > [2] https://lore.kernel.org/lkml/20240303235029.555787150@linutronix.de/ thanks, -- js suse labs
On 6/6/25 02:17, Jiri Slaby wrote: > Given this is the second time I hit a bug with this, perhaps introduce > an EXPERIMENTAL CONFIG option, so that random users can simply disable > it if an issue occurs? Without the need of patching random userspace and > changing random kernel headers? What about something like the attached (untested) patch? That should at least get folks back to the old, universal working behavior even when using new compilers.
On Fri, Jun 6, 2025 at 5:44 PM Dave Hansen <dave.hansen@intel.com> wrote: > > On 6/6/25 02:17, Jiri Slaby wrote: > > Given this is the second time I hit a bug with this, perhaps introduce > > an EXPERIMENTAL CONFIG option, so that random users can simply disable > > it if an issue occurs? Without the need of patching random userspace and > > changing random kernel headers? > > What about something like the attached (untested) patch? That should at > least get folks back to the old, universal working behavior even when > using new compilers. IMO the commit message is unnecessarily overly dramatic. The "nasty bugs" were in fact: - unfortunate mix of clang < 19 and new gcc-14 [1], fixed by robustifying the detection of typeof_unqual [1] https://lore.kernel.org/lkml/CA+G9fYuP2bHnDvJwfMm6+8Y8UYk74qCw-2HsFyRzJDFiQ5dbpQ@mail.gmail.com/ - sparse doesn't understand new keyword, patch at [2], but sparse is effectively unmaintained so a workaround is in place [2] https://lore.kernel.org/linux-sparse/5b8d0dee-8fb6-45af-ba6c-7f74aff9a4b8@stanley.mountain/ - genksyms didn't understand the new keyword, fixed by [3]. [3] https://lore.kernel.org/lkml/174461594538.31282.5752735096854392083.tip-bot2@tip-bot2/ - a performance regression, again due to the unfortunate usage of old gcc-13 [4]. The new gcc-14 would break compilation due to the missing __percpu qualifier. This is one of the examples, where new checks would prevent the issue during the development. Fixed with the help of gcc-14. [4] https://lore.kernel.org/all/CAADnVQ+iFBxauKq99=-Xk+BdG+Lv=Xgvwi1dC4fpG0utmXJiiA@mail.gmail.com/ - the issue in this thread, already fixed/worked around. Looking at the fix, I don't think gcc is at fault, but I speculate that there could be some invalid assumption about dwarf representation of variables in non-default address space at play. I'll look at this one in some more detail. Please also note that besides the above issues, the GCC type system and related checks around named address spaces was rock solid; there were *zero* bugs regarding __percpu variables, and the referred patch moves *all of them* to __seg_gs named address space. The patch builds off an equally stable and now well proven GCC named address space support, so in my opinion, it *is* ready for prime time. As demonstrated in the above list of issues, it was *never* the compiler at fault. Let me reiterate what the patch brings to the table. It prevents invalid references of per cpu variables to non-percpu locations. One missing percpu dereference can have disastrous consequences (all CPUs will access data in the shared space). Currently, the safety builds on checking sparse logs, but sparse errors don't break the build. With new checks in place, *every* invalid access is detected and breaks the build with some 50 lines of errors. Hiding these checks behind the CONFIG_EXPERT option breaks the intention of the patch. IMO, it should be always enabled to avoid errors, mentioned in the previous paragraph, already during the development time. I'm much more inclined to James' proposal. Maybe we can disable these checks in v6.15 stable series, but leave them in v6.16? This would leave a couple of months for distributions to update libbpf. Thanks, Uros.
On 6/7/25 01:52, Uros Bizjak wrote: > Let me reiterate what the patch brings to the table. It prevents > invalid references of per cpu variables to non-percpu locations. Yes, it's a very useful mechanism. That's exactly why I want to preserve it for developers or things like 0day that do build tests and don't care about modules quadrupling in size. > Hiding these checks behind the CONFIG_EXPERT option breaks the > intention of the patch. IMO, it should be always enabled to avoid > errors, mentioned in the previous paragraph, already during the > development time. I agree, it should always be enabled ... eventually. But now now. That's why we're having this conversation: it's breaking too many things and needs to be disabled. > I'm much more inclined to James' proposal. Maybe we can disable these > checks in v6.15 stable series, but leave them in v6.16? This would > leave a couple of months for distributions to update libbpf. I'd be worried that it will hit a whole bunch of folks doing 6.16 work. I was expecting to revert it _everywhere_ for now, if we go the revert route. James, by partial revert, did you mean to revert in stable but not mainline? I assumed you meant to just revert patch 6/6 of the series (stable and mainline) but leave 1-5 in place so turning it back on later was easier.
On Sat, 2025-06-07 at 07:12 -0700, Dave Hansen wrote: [...] > James, by partial revert, did you mean to revert in stable but not > mainline? I assumed you meant to just revert patch 6/6 of the series > (stable and mainline) but leave 1-5 in place so turning it back on > later was easier. No, we had to put the revert through mainline because too many people who build their own kernels use the firmware service. We definitely didn't revert the entire series. I constructed a new patch which was effectively a partial revert only of the behaviour that was tickling the bug. For the record, this was the series containing the problem: https://lore.kernel.org/all/20250119151214.23562-1-James.Bottomley@HansenPartnership.com/ And this is the revert we eventually came up with: https://lore.kernel.org/all/63837c36eceaf8cf2af7933dccca54ff4dd9f30d.camel@HansenPartnership.com/ So it was specifically not a general revert but a narrowly crafted one to get firmware services working again. The mechanism we did was to queue the revert as an -rc fix so it went in immediately and got backported to stable and then queue the revert of the revert for the next merge window (and check before sending to Linus that the user space update had spread far enough otherwise we'd have skipped to the merge window after). Regards, James
On Fri, Jun 6, 2025 at 11:17 AM Jiri Slaby <jirislaby@kernel.org> wrote: > > On 05. 06. 25, 19:31, Uros Bizjak wrote: > > On Thu, Jun 5, 2025 at 7:15 PM Dave Hansen <dave.hansen@intel.com> wrote: > >> > >> On 6/5/25 07:27, Jiri Slaby wrote: > >>> Reverting this gives me back to normal sizes. > >>> > >>> Any ideas? > >> > >> I don't see any reason not to revert it. The benefits weren't exactly > >> clear from the changelogs or cover letter. Enabling "various compiler > >> checks" doesn't exactly scream that this is critical to end users in > >> some way. > >> > >> The only question is if we revert just this last patch or the whole series. > >> > >> Uros, is there an alternative to reverting? > > > > This functionality can easily be disabled in include/linux/compiler.h > > by not defining USE_TYPEOF_UNQUAL: > > > > #if CC_HAS_TYPEOF_UNQUAL && !defined(__CHECKER__) > > # define USE_TYPEOF_UNQUAL 1 > > #endif > > > > (support for typeof_unqual keyword is required to handle __seg_gs > > qualifiers), but ... > > > > ... the issue is reportedly fixed, please see [1], and ... > > Confirmed, I need a patched userspace (libbpf). > > > ... you will disable much sought of feature, just ask tglx (and please > > read his rant at [2]): > > Given this is the second time I hit a bug with this, perhaps introduce > an EXPERIMENTAL CONFIG option, so that random users can simply disable > it if an issue occurs? Without the need of patching random userspace and > changing random kernel headers? In both cases, the patch *exposed* a bug in a related utility software, it is not that the patch itself is buggy. IMO, waving off the issue by disabling the feature you just risk the bug in the related software to hit even harder in some not too distant future. Uros.
On Fri, Jun 6, 2025 at 2:27 AM Uros Bizjak <ubizjak@gmail.com> wrote: > > On Fri, Jun 6, 2025 at 11:17 AM Jiri Slaby <jirislaby@kernel.org> wrote: > > > > On 05. 06. 25, 19:31, Uros Bizjak wrote: > > > On Thu, Jun 5, 2025 at 7:15 PM Dave Hansen <dave.hansen@intel.com> wrote: > > >> > > >> On 6/5/25 07:27, Jiri Slaby wrote: > > >>> Reverting this gives me back to normal sizes. > > >>> > > >>> Any ideas? > > >> > > >> I don't see any reason not to revert it. The benefits weren't exactly > > >> clear from the changelogs or cover letter. Enabling "various compiler > > >> checks" doesn't exactly scream that this is critical to end users in > > >> some way. > > >> > > >> The only question is if we revert just this last patch or the whole series. > > >> > > >> Uros, is there an alternative to reverting? > > > > > > This functionality can easily be disabled in include/linux/compiler.h > > > by not defining USE_TYPEOF_UNQUAL: > > > > > > #if CC_HAS_TYPEOF_UNQUAL && !defined(__CHECKER__) > > > # define USE_TYPEOF_UNQUAL 1 > > > #endif > > > > > > (support for typeof_unqual keyword is required to handle __seg_gs > > > qualifiers), but ... > > > > > > ... the issue is reportedly fixed, please see [1], and ... > > > > Confirmed, I need a patched userspace (libbpf). > > > > > ... you will disable much sought of feature, just ask tglx (and please > > > read his rant at [2]): > > > > Given this is the second time I hit a bug with this, perhaps introduce > > an EXPERIMENTAL CONFIG option, so that random users can simply disable > > it if an issue occurs? Without the need of patching random userspace and > > changing random kernel headers? > > In both cases, the patch *exposed* a bug in a related utility > software, it is not that the patch itself is buggy. IMO, waving off > the issue by disabling the feature you just risk the bug in the > related software to hit even harder in some not too distant future. The typeof_unqual exposed the issue in the way GCC generates dwarf. The libbpf/pahole is a workaround for incorrect dwarf. The compiler shouldn't emit two identical dwarf definition for one underlying type within one compilation unit. In this case typeof_unqual somehow confused gcc.
On Fri, Jun 6, 2025 at 6:39 PM Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > > On Fri, Jun 6, 2025 at 2:27 AM Uros Bizjak <ubizjak@gmail.com> wrote: > > > > On Fri, Jun 6, 2025 at 11:17 AM Jiri Slaby <jirislaby@kernel.org> wrote: > > > > > > On 05. 06. 25, 19:31, Uros Bizjak wrote: > > > > On Thu, Jun 5, 2025 at 7:15 PM Dave Hansen <dave.hansen@intel.com> wrote: > > > >> > > > >> On 6/5/25 07:27, Jiri Slaby wrote: > > > >>> Reverting this gives me back to normal sizes. > > > >>> > > > >>> Any ideas? > > > >> > > > >> I don't see any reason not to revert it. The benefits weren't exactly > > > >> clear from the changelogs or cover letter. Enabling "various compiler > > > >> checks" doesn't exactly scream that this is critical to end users in > > > >> some way. > > > >> > > > >> The only question is if we revert just this last patch or the whole series. > > > >> > > > >> Uros, is there an alternative to reverting? > > > > > > > > This functionality can easily be disabled in include/linux/compiler.h > > > > by not defining USE_TYPEOF_UNQUAL: > > > > > > > > #if CC_HAS_TYPEOF_UNQUAL && !defined(__CHECKER__) > > > > # define USE_TYPEOF_UNQUAL 1 > > > > #endif > > > > > > > > (support for typeof_unqual keyword is required to handle __seg_gs > > > > qualifiers), but ... > > > > > > > > ... the issue is reportedly fixed, please see [1], and ... > > > > > > Confirmed, I need a patched userspace (libbpf). > > > > > > > ... you will disable much sought of feature, just ask tglx (and please > > > > read his rant at [2]): > > > > > > Given this is the second time I hit a bug with this, perhaps introduce > > > an EXPERIMENTAL CONFIG option, so that random users can simply disable > > > it if an issue occurs? Without the need of patching random userspace and > > > changing random kernel headers? > > > > In both cases, the patch *exposed* a bug in a related utility > > software, it is not that the patch itself is buggy. IMO, waving off > > the issue by disabling the feature you just risk the bug in the > > related software to hit even harder in some not too distant future. > > The typeof_unqual exposed the issue in the way GCC generates dwarf. > The libbpf/pahole is a workaround for incorrect dwarf. > The compiler shouldn't emit two identical dwarf definition for > one underlying type within one compilation unit. In this case > typeof_unqual somehow confused gcc. Can you please file a bugreport in GCC bugzilla, so we can analyze the issue? Uros.
On Fri, 2025-06-06 at 11:27 +0200, Uros Bizjak wrote: > On Fri, Jun 6, 2025 at 11:17 AM Jiri Slaby <jirislaby@kernel.org> > wrote: [...] > > Given this is the second time I hit a bug with this, perhaps > > introduce an EXPERIMENTAL CONFIG option, so that random users can > > simply disable it if an issue occurs? Without the need of patching > > random userspace and changing random kernel headers? > > In both cases, the patch *exposed* a bug in a related utility > software, it is not that the patch itself is buggy. IMO, waving off > the issue by disabling the feature you just risk the bug in the > related software to hit even harder in some not too distant future. Given the severity of the problem absent tools updates the usual way of handling this is a (sometimes partial) revert for the estimated time to fix the tool chain followed by a resend. This is exactly what we did when an efivarfs bug fixe exposed a bug in the firmware update service: https://lore.kernel.org/all/ffd953c76d3a0bc0f88aeb319589632e8da032dc.camel@HansenPartnership.com/ It only took about 3 months to get the update through the distros, what would the estimate for this be? Regards, James
* Jiri Slaby (jirislaby@kernel.org) wrote:
> On 27. 01. 25, 17:05, Uros Bizjak wrote:
> > This patch declares percpu variables in __seg_gs/__seg_fs named AS
> > and keeps them named AS qualified until they are dereferenced with
> > percpu accessor. This approach enables various compiler check
> > for cross-namespace variable assignments.
> >
> > Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
> > Acked-by: Nadav Amit <nadav.amit@gmail.com>
> > Cc: Dennis Zhou <dennis@kernel.org>
> > Cc: Tejun Heo <tj@kernel.org>
> > Cc: Christoph Lameter <cl@linux.com>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Ingo Molnar <mingo@kernel.org>
> > Cc: Borislav Petkov <bp@alien8.de>
> > Cc: Dave Hansen <dave.hansen@linux.intel.com>
> > Cc: "H. Peter Anvin" <hpa@zytor.com>
> > Cc: Linus Torvalds <torvalds@linux-foundation.org>
> > Cc: Andy Lutomirski <luto@kernel.org>
> > Cc: Brian Gerst <brgerst@gmail.com>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > ---
> > arch/x86/include/asm/percpu.h | 15 ++++++++++++---
> > 1 file changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h
> > index 27f668660abe..474d648bca9a 100644
> > --- a/arch/x86/include/asm/percpu.h
> > +++ b/arch/x86/include/asm/percpu.h
> > @@ -95,9 +95,18 @@
> > #endif /* CONFIG_SMP */
> > -#define __my_cpu_type(var) typeof(var) __percpu_seg_override
> > -#define __my_cpu_ptr(ptr) (__my_cpu_type(*(ptr))*)(__force uintptr_t)(ptr)
> > -#define __my_cpu_var(var) (*__my_cpu_ptr(&(var)))
> > +#if defined(CONFIG_USE_X86_SEG_SUPPORT) && defined(USE_TYPEOF_UNQUAL)
> > +# define __my_cpu_type(var) typeof(var)
> > +# define __my_cpu_ptr(ptr) (ptr)
> > +# define __my_cpu_var(var) (var)
> > +
> > +# define __percpu_qual __percpu_seg_override
> > +#else
> > +# define __my_cpu_type(var) typeof(var) __percpu_seg_override
> > +# define __my_cpu_ptr(ptr) (__my_cpu_type(*(ptr))*)(__force uintptr_t)(ptr)
> > +# define __my_cpu_var(var) (*__my_cpu_ptr(&(var)))
> > +#endif
> > +
>
> Another issue with this is this causes all modules in 6.15 are 2-4 times
> (compressed size) bigger:
Oh, is that why config-all kernel is too big?
Dave
> $ ll /usr/lib/modules/*-[0-9]-default/kernel/drivers/atm/atmtcp.ko.zst
> > -rw-r--r--. 1 root root 10325 May 13 11:49
> /usr/lib/modules/6.14.6-2-default/kernel/drivers/atm/atmtcp.ko.zst
> > -rw-r--r--. 1 root root 39677 Jun 2 09:13
> /usr/lib/modules/6.15.0-1-default/kernel/drivers/atm/atmtcp.ko.zst
>
> It's due to larger .BTF section:
> .BTF PROGBITS 0000000000000000 [-00003080-]
> [- 00000000000011a8-] {+00003100+}
> {+ 0000000000012cf8+} 0000000000000000 0 0 1
>
> There are a lot of new BTF types defined in each module like:
> +attribute_group STRUCT
> +backing_dev_info STRUCT
> +bdi_writeback STRUCT
> +bin_attribute STRUCT
> +bio_end_io_t TYPEDEF
> +bio_list STRUCT
> +bio_set STRUCT
> +bio STRUCT
> +bio_vec STRUCT
>
> Reverting this gives me back to normal sizes.
>
> Any ideas?
>
> FTR downstream report:
> https://bugzilla.suse.com/show_bug.cgi?id=1244135
>
> thanks,
> --
> js
> suse labs
>
>
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ dave @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
Cc BPF people, just so you know.
On 05. 06. 25, 16:27, Jiri Slaby wrote:
> On 27. 01. 25, 17:05, Uros Bizjak wrote:
>> This patch declares percpu variables in __seg_gs/__seg_fs named AS
>> and keeps them named AS qualified until they are dereferenced with
>> percpu accessor. This approach enables various compiler check
>> for cross-namespace variable assignments.
>>
>> Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
>> Acked-by: Nadav Amit <nadav.amit@gmail.com>
>> Cc: Dennis Zhou <dennis@kernel.org>
>> Cc: Tejun Heo <tj@kernel.org>
>> Cc: Christoph Lameter <cl@linux.com>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Ingo Molnar <mingo@kernel.org>
>> Cc: Borislav Petkov <bp@alien8.de>
>> Cc: Dave Hansen <dave.hansen@linux.intel.com>
>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>> Cc: Linus Torvalds <torvalds@linux-foundation.org>
>> Cc: Andy Lutomirski <luto@kernel.org>
>> Cc: Brian Gerst <brgerst@gmail.com>
>> Cc: Peter Zijlstra <peterz@infradead.org>
>> ---
>> arch/x86/include/asm/percpu.h | 15 ++++++++++++---
>> 1 file changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/
>> percpu.h
>> index 27f668660abe..474d648bca9a 100644
>> --- a/arch/x86/include/asm/percpu.h
>> +++ b/arch/x86/include/asm/percpu.h
>> @@ -95,9 +95,18 @@
>> #endif /* CONFIG_SMP */
>> -#define __my_cpu_type(var) typeof(var) __percpu_seg_override
>> -#define __my_cpu_ptr(ptr) (__my_cpu_type(*(ptr))*)(__force
>> uintptr_t)(ptr)
>> -#define __my_cpu_var(var) (*__my_cpu_ptr(&(var)))
>> +#if defined(CONFIG_USE_X86_SEG_SUPPORT) && defined(USE_TYPEOF_UNQUAL)
>> +# define __my_cpu_type(var) typeof(var)
>> +# define __my_cpu_ptr(ptr) (ptr)
>> +# define __my_cpu_var(var) (var)
>> +
>> +# define __percpu_qual __percpu_seg_override
>> +#else
>> +# define __my_cpu_type(var) typeof(var) __percpu_seg_override
>> +# define __my_cpu_ptr(ptr) (__my_cpu_type(*(ptr))*)(__force
>> uintptr_t)(ptr)
>> +# define __my_cpu_var(var) (*__my_cpu_ptr(&(var)))
>> +#endif
>> +
>
> Another issue with this is this causes all modules in 6.15 are 2-4 times
> (compressed size) bigger:
> $ ll /usr/lib/modules/*-[0-9]-default/kernel/drivers/atm/atmtcp.ko.zst
> > -rw-r--r--. 1 root root 10325 May 13 11:49 /usr/lib/modules/6.14.6-2-
> default/kernel/drivers/atm/atmtcp.ko.zst
> > -rw-r--r--. 1 root root 39677 Jun 2 09:13 /usr/lib/modules/6.15.0-1-
> default/kernel/drivers/atm/atmtcp.ko.zst
>
> It's due to larger .BTF section:
> .BTF PROGBITS 0000000000000000 [-00003080-]
> [- 00000000000011a8-] {+00003100+}
> {+ 0000000000012cf8+} 0000000000000000 0 0 1
>
> There are a lot of new BTF types defined in each module like:
> +attribute_group STRUCT
> +backing_dev_info STRUCT
> +bdi_writeback STRUCT
> +bin_attribute STRUCT
> +bio_end_io_t TYPEDEF
> +bio_list STRUCT
> +bio_set STRUCT
> +bio STRUCT
> +bio_vec STRUCT
>
> Reverting this gives me back to normal sizes.
>
> Any ideas?
>
> FTR downstream report:
> https://bugzilla.suse.com/show_bug.cgi?id=1244135
>
> thanks,
--
js
suse labs
On Thu, Jun 5, 2025 at 7:32 AM Jiri Slaby <jirislaby@kernel.org> wrote:
>
> Cc BPF people, just so you know.
>
> On 05. 06. 25, 16:27, Jiri Slaby wrote:
> > On 27. 01. 25, 17:05, Uros Bizjak wrote:
> >> This patch declares percpu variables in __seg_gs/__seg_fs named AS
> >> and keeps them named AS qualified until they are dereferenced with
> >> percpu accessor. This approach enables various compiler check
> >> for cross-namespace variable assignments.
> >>
> >> Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
> >> Acked-by: Nadav Amit <nadav.amit@gmail.com>
> >> Cc: Dennis Zhou <dennis@kernel.org>
> >> Cc: Tejun Heo <tj@kernel.org>
> >> Cc: Christoph Lameter <cl@linux.com>
> >> Cc: Thomas Gleixner <tglx@linutronix.de>
> >> Cc: Ingo Molnar <mingo@kernel.org>
> >> Cc: Borislav Petkov <bp@alien8.de>
> >> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> >> Cc: "H. Peter Anvin" <hpa@zytor.com>
> >> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> >> Cc: Andy Lutomirski <luto@kernel.org>
> >> Cc: Brian Gerst <brgerst@gmail.com>
> >> Cc: Peter Zijlstra <peterz@infradead.org>
> >> ---
> >> arch/x86/include/asm/percpu.h | 15 ++++++++++++---
> >> 1 file changed, 12 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/
> >> percpu.h
> >> index 27f668660abe..474d648bca9a 100644
> >> --- a/arch/x86/include/asm/percpu.h
> >> +++ b/arch/x86/include/asm/percpu.h
> >> @@ -95,9 +95,18 @@
> >> #endif /* CONFIG_SMP */
> >> -#define __my_cpu_type(var) typeof(var) __percpu_seg_override
> >> -#define __my_cpu_ptr(ptr) (__my_cpu_type(*(ptr))*)(__force
> >> uintptr_t)(ptr)
> >> -#define __my_cpu_var(var) (*__my_cpu_ptr(&(var)))
> >> +#if defined(CONFIG_USE_X86_SEG_SUPPORT) && defined(USE_TYPEOF_UNQUAL)
> >> +# define __my_cpu_type(var) typeof(var)
> >> +# define __my_cpu_ptr(ptr) (ptr)
> >> +# define __my_cpu_var(var) (var)
> >> +
> >> +# define __percpu_qual __percpu_seg_override
> >> +#else
> >> +# define __my_cpu_type(var) typeof(var) __percpu_seg_override
> >> +# define __my_cpu_ptr(ptr) (__my_cpu_type(*(ptr))*)(__force
> >> uintptr_t)(ptr)
> >> +# define __my_cpu_var(var) (*__my_cpu_ptr(&(var)))
> >> +#endif
> >> +
> >
> > Another issue with this is this causes all modules in 6.15 are 2-4 times
> > (compressed size) bigger:
> > $ ll /usr/lib/modules/*-[0-9]-default/kernel/drivers/atm/atmtcp.ko.zst
> > > -rw-r--r--. 1 root root 10325 May 13 11:49 /usr/lib/modules/6.14.6-2-
> > default/kernel/drivers/atm/atmtcp.ko.zst
> > > -rw-r--r--. 1 root root 39677 Jun 2 09:13 /usr/lib/modules/6.15.0-1-
> > default/kernel/drivers/atm/atmtcp.ko.zst
> >
> > It's due to larger .BTF section:
> > .BTF PROGBITS 0000000000000000 [-00003080-]
> > [- 00000000000011a8-] {+00003100+}
> > {+ 0000000000012cf8+} 0000000000000000 0 0 1
> >
> > There are a lot of new BTF types defined in each module like:
> > +attribute_group STRUCT
> > +backing_dev_info STRUCT
> > +bdi_writeback STRUCT
> > +bin_attribute STRUCT
> > +bio_end_io_t TYPEDEF
> > +bio_list STRUCT
> > +bio_set STRUCT
> > +bio STRUCT
> > +bio_vec STRUCT
> >
> > Reverting this gives me back to normal sizes.
> >
> > Any ideas?
Try newer pahole ?
It was fixed by:
https://lore.kernel.org/bpf/20250429161042.2069678-1-alan.maguire@oracle.com/
© 2016 - 2025 Red Hat, Inc.