Re: [PATCH 1/2] [RFC] debugobjects: avoid gcc-16.0.1 section mismatch

Re: [PATCH 1/2] [RFC] debugobjects: avoid gcc-16.0.1 section mismatch

[Heiko Carstens]

On Tue, Feb 03, 2026 at 05:23:59PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> gcc-16 has gained some more advanced inlining techniques that enable
> it to inline the is_static_object() function pointer into a specialized
> version of lookup_object_or_alloc:
> 
> WARNING: modpost: vmlinux: section mismatch in reference: lookup_object_or_alloc.part.0+0x1ac (section: .text) -> is_static_object (section: .init.text)
> 
> >From what I can tell, the transformation is correct, as this
> is only called when lookup_object_or_alloc() is called from
> debug_objects_selftest(), which is also __init.
> 
> I have not come up with a good workaround, so this simply marks
> is_static_object() as not __init. Since there are currently only two
> files where this happens, that may be an easy way out.
> 
> If anyone has a better idea for how to deal with that, let me know!
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  lib/debugobjects.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

FWIW, I'm seeing this now on s390 with gcc-16 too (debug_defconfig).

> diff --git a/lib/debugobjects.c b/lib/debugobjects.c
> index 89a1d6745dc2..056957c4e52f 100644
> --- a/lib/debugobjects.c
> +++ b/lib/debugobjects.c
> @@ -1195,7 +1195,7 @@ struct self_test {
>  
>  static __initconst const struct debug_obj_descr descr_type_test;
>  
> -static bool __init is_static_object(void *addr)
> +static bool is_static_object(void *addr)
>  {
>  	struct self_test *obj = addr;
>  
> -- 
> 2.39.5
> 

Re: [PATCH 1/2] [RFC] debugobjects: avoid gcc-16.0.1 section mismatch

[Thomas Gleixner]

On Tue, Feb 03 2026 at 17:23, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> gcc-16 has gained some more advanced inlining techniques that enable
> it to inline the is_static_object() function pointer into a specialized
> version of lookup_object_or_alloc:
>
> WARNING: modpost: vmlinux: section mismatch in reference: lookup_object_or_alloc.part.0+0x1ac (section: .text) -> is_static_object (section: .init.text)
>
> From what I can tell, the transformation is correct, as this
> is only called when lookup_object_or_alloc() is called from
> debug_objects_selftest(), which is also __init.

So clearly the compiler is buggy. It creates an __init specific copy of
lookup_object_or_alloc() and then fails to attribute it correctly.

> I have not come up with a good workaround, so this simply marks
> is_static_object() as not __init. Since there are currently only two
> files where this happens, that may be an easy way out.

That's a horrible hack and while it's only two files today, this sounds
like the start of a whack a mole game.

Aside of that five weeks down the road some clever AI bot creates a
patch which marks the function __init again (rightfully so).

> If anyone has a better idea for how to deal with that, let me know!

Mark the compiler broken and wait until GCC people get their act
together.

Thanks,

        tglx

Re: [PATCH 1/2] [RFC] debugobjects: avoid gcc-16.0.1 section mismatch

[Arnd Bergmann]

On Sun, May 10, 2026, at 21:31, Thomas Gleixner wrote:
> On Tue, Feb 03 2026 at 17:23, Arnd Bergmann wrote:
>> From: Arnd Bergmann <arnd@arndb.de>
>>
>> gcc-16 has gained some more advanced inlining techniques that enable
>> it to inline the is_static_object() function pointer into a specialized
>> version of lookup_object_or_alloc:
>>
>> WARNING: modpost: vmlinux: section mismatch in reference: lookup_object_or_alloc.part.0+0x1ac (section: .text) -> is_static_object (section: .init.text)
>>
>> From what I can tell, the transformation is correct, as this
>> is only called when lookup_object_or_alloc() is called from
>> debug_objects_selftest(), which is also __init.
>
> So clearly the compiler is buggy. It creates an __init specific copy of
> lookup_object_or_alloc() and then fails to attribute it correctly.

I don't see what else the compiler is supposed to do, it has no idea what
__init means in the kernel, or what the rules are for calling between
that and normal functions. Putting a non-inlined lookup_object_or_alloc()
into a special section without an explicit attribute would clearly
be a bug.

>> I have not come up with a good workaround, so this simply marks
>> is_static_object() as not __init. Since there are currently only two
>> files where this happens, that may be an easy way out.
>
> That's a horrible hack and while it's only two files today, this sounds
> like the start of a whack a mole game.

After thousands of randconfig builds, I found exactly the two
instances from this series.

Since this only happens in a very specific case where a file
uses function pointers to local functions and gcc is able
to turn these into direct calls, I wouldn't expect this to
become a widespread problem. It's normal for new compiler
versions to run into some corner cases like this when inlining
decisions change.

>> If anyone has a better idea for how to deal with that, let me know!
>
> Mark the compiler broken and wait until GCC people get their act
> together.

I'll have to retest with the actual release compiler, maybe they
changed something again that makes it go away already, otherwise
there is probably a flag to tell gcc to skip that optimization pass.

       Arnd

Re: [PATCH 1/2] [RFC] debugobjects: avoid gcc-16.0.1 section mismatch

[Thomas Gleixner]

On Mon, May 11 2026 at 08:17, Arnd Bergmann wrote:
> On Sun, May 10, 2026, at 21:31, Thomas Gleixner wrote:
>> On Tue, Feb 03 2026 at 17:23, Arnd Bergmann wrote:
>>> WARNING: modpost: vmlinux: section mismatch in reference: lookup_object_or_alloc.part.0+0x1ac (section: .text) -> is_static_object (section: .init.text)
>>>
>>> From what I can tell, the transformation is correct, as this
>>> is only called when lookup_object_or_alloc() is called from
>>> debug_objects_selftest(), which is also __init.
>>
>> So clearly the compiler is buggy. It creates an __init specific copy of
>> lookup_object_or_alloc() and then fails to attribute it correctly.
>
> I don't see what else the compiler is supposed to do, it has no idea what
> __init means in the kernel, or what the rules are for calling between
> that and normal functions. Putting a non-inlined lookup_object_or_alloc()
> into a special section without an explicit attribute would clearly
> be a bug.

I agree that the compiler does not know what __init means, but this
sucks as it leaves an unused copy of lookup_object_or_alloc() around
after init.

What happens if you mark is_static_object() with 'noinline'?

Thanks,

        tglx

Re: [PATCH 1/2] [RFC] debugobjects: avoid gcc-16.0.1 section mismatch

[Arnd Bergmann]

On Mon, May 11, 2026, at 09:18, Thomas Gleixner wrote:
> On Mon, May 11 2026 at 08:17, Arnd Bergmann wrote:
>> On Sun, May 10, 2026, at 21:31, Thomas Gleixner wrote:
>>> On Tue, Feb 03 2026 at 17:23, Arnd Bergmann wrote:
>>>> WARNING: modpost: vmlinux: section mismatch in reference: lookup_object_or_alloc.part.0+0x1ac (section: .text) -> is_static_object (section: .init.text)
>>>>
>>>> From what I can tell, the transformation is correct, as this
>>>> is only called when lookup_object_or_alloc() is called from
>>>> debug_objects_selftest(), which is also __init.
>>>
>>> So clearly the compiler is buggy. It creates an __init specific copy of
>>> lookup_object_or_alloc() and then fails to attribute it correctly.
>>
>> I don't see what else the compiler is supposed to do, it has no idea what
>> __init means in the kernel, or what the rules are for calling between
>> that and normal functions. Putting a non-inlined lookup_object_or_alloc()
>> into a special section without an explicit attribute would clearly
>> be a bug.
>
> I agree that the compiler does not know what __init means, but this
> sucks as it leaves an unused copy of lookup_object_or_alloc() around
> after init.
>
> What happens if you mark is_static_object() with 'noinline'?

I've reproduced the issue with the release gcc-16.1.0 build,
and tested marking is_static_object (along with
dummy_tlb_add_page and dummy_tlb_flush from the other
instance) as noinline.

As expected, this avoids the problem as well.

      Arnd

diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
index 40e33257d3c2..b89dcf167832 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -782,16 +782,17 @@ static void __init dummy_tlb_flush_all(void *cookie)
 	WARN_ON(cookie != cfg_cookie);
 }
 
-static void __init dummy_tlb_flush(unsigned long iova, size_t size,
-				   size_t granule, void *cookie)
+static noinline void __init dummy_tlb_flush(unsigned long iova, size_t size,
+					    size_t granule, void *cookie)
 {
 	WARN_ON(cookie != cfg_cookie);
 	WARN_ON(!(size & cfg_cookie->pgsize_bitmap));
 }
 
-static void __init dummy_tlb_add_page(struct iommu_iotlb_gather *gather,
-				      unsigned long iova, size_t granule,
-				      void *cookie)
+static noinline void __init dummy_tlb_add_page(struct iommu_iotlb_gather *gather,
+					       unsigned long iova,
+					       size_t granule,
+					       void *cookie)
 {
 	dummy_tlb_flush(iova, granule, granule, cookie);
 }
diff --git a/lib/debugobjects.c b/lib/debugobjects.c
index 12e2e42e6a31..18253cb03701 100644
--- a/lib/debugobjects.c
+++ b/lib/debugobjects.c
@@ -1212,7 +1212,7 @@ struct self_test {
 
 static __initconst const struct debug_obj_descr descr_type_test;
 
-static bool __init is_static_object(void *addr)
+static noinline bool __init is_static_object(void *addr)
 {
 	struct self_test *obj = addr;
 

Re: [PATCH 1/2] [RFC] debugobjects: avoid gcc-16.0.1 section mismatch

[Thomas Gleixner]

On Mon, May 11 2026 at 11:46, Arnd Bergmann wrote:
> On Mon, May 11, 2026, at 09:18, Thomas Gleixner wrote:
>> I agree that the compiler does not know what __init means, but this
>> sucks as it leaves an unused copy of lookup_object_or_alloc() around
>> after init.
>>
>> What happens if you mark is_static_object() with 'noinline'?
>
> I've reproduced the issue with the release gcc-16.1.0 build,
> and tested marking is_static_object (along with
> dummy_tlb_add_page and dummy_tlb_flush from the other
> instance) as noinline.
>
> As expected, this avoids the problem as well.

I rather prefer that along with a comment explaining the 'noinline' oddity.