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

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

[Arnd Bergmann]

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(-)

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

[PATCH 2/2] [RFC] iommu: io-pgtable-arm-v7s: avoid gcc-16.0.1 section mismatch

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

gcc-16 has gained some more advanced inlining techniques that enable
it to inline the dummy_tlb_add_page() and dummy_tlb_flush() function
pointers into a specialized version of __arm_v7s_unmap:

WARNING: modpost: vmlinux: section mismatch in reference: __arm_v7s_unmap+0x2cc (section: .text) -> dummy_tlb_add_page (section: .init.text)

From what I can tell, the transformation is correct, as this
is only called when __arm_v7s_unmap() is called from
arm_v7s_do_selftests(), which is also __init.

I have not come up with a good workaround, so this simply marks
dummy_tlb_add_page() 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>
---
 drivers/iommu/io-pgtable-arm-v7s.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
index 523355e91a2c..705885924afb 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -775,23 +775,23 @@ struct io_pgtable_init_fns io_pgtable_arm_v7s_init_fns = {
 
 #ifdef CONFIG_IOMMU_IO_PGTABLE_ARMV7S_SELFTEST
 
-static struct io_pgtable_cfg *cfg_cookie __initdata;
+static struct io_pgtable_cfg *cfg_cookie;
 
 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,
+static void 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 void dummy_tlb_add_page(struct iommu_iotlb_gather *gather,
+			       unsigned long iova, size_t granule,
+			       void *cookie)
 {
 	dummy_tlb_flush(iova, granule, granule, cookie);
 }
-- 
2.39.5

Re: [PATCH 2/2] [RFC] iommu: io-pgtable-arm-v7s: avoid gcc-16.0.1 section mismatch

[Will Deacon]

On Tue, Feb 03, 2026 at 05:24:00PM +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 dummy_tlb_add_page() and dummy_tlb_flush() function
> pointers into a specialized version of __arm_v7s_unmap:
> 
> WARNING: modpost: vmlinux: section mismatch in reference: __arm_v7s_unmap+0x2cc (section: .text) -> dummy_tlb_add_page (section: .init.text)
> 
> From what I can tell, the transformation is correct, as this
> is only called when __arm_v7s_unmap() is called from
> arm_v7s_do_selftests(), which is also __init.
> 
> I have not come up with a good workaround, so this simply marks
> dummy_tlb_add_page() 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!

Can we mark the dummy_* functions as 'noinline' instead? We shouldn't
have to keep the selftest code kicking around in memory after boot.

Will

Re: [PATCH 2/2] [RFC] iommu: io-pgtable-arm-v7s: avoid gcc-16.0.1 section mismatch

[Arnd Bergmann]

On Tue, Mar 10, 2026, at 17:40, Will Deacon wrote:
> On Tue, Feb 03, 2026 at 05:24:00PM +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 dummy_tlb_add_page() and dummy_tlb_flush() function
>> pointers into a specialized version of __arm_v7s_unmap:
>> 
>> WARNING: modpost: vmlinux: section mismatch in reference: __arm_v7s_unmap+0x2cc (section: .text) -> dummy_tlb_add_page (section: .init.text)
>> 
>> From what I can tell, the transformation is correct, as this
>> is only called when __arm_v7s_unmap() is called from
>> arm_v7s_do_selftests(), which is also __init.
>> 
>> I have not come up with a good workaround, so this simply marks
>> dummy_tlb_add_page() 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!
>
> Can we mark the dummy_* functions as 'noinline' instead? We shouldn't
> have to keep the selftest code kicking around in memory after boot.

I think that would work as well, but I'd have to test it properly,
as the gcc behavior was already not what I had expected.

Another option may be to take this a bit further and do the
same for the arm_v7s selftest that Mostafa did in the lpae
selftest with 7e06063a43d3 ("iommu/io-pgtable-arm-selftests:
Use KUnit") and a3c24b6d7cd6 ("iommu/io-pgtable-arm-selftests:
Modularize the test").

I think that would be the most logical step, but it's also
beyond what I can do as a simple build fix.

     Arnd

Re: [PATCH 2/2] [RFC] iommu: io-pgtable-arm-v7s: avoid gcc-16.0.1 section mismatch

[Will Deacon]

On Tue, Mar 10, 2026 at 08:26:40PM +0100, Arnd Bergmann wrote:
> On Tue, Mar 10, 2026, at 17:40, Will Deacon wrote:
> > On Tue, Feb 03, 2026 at 05:24:00PM +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 dummy_tlb_add_page() and dummy_tlb_flush() function
> >> pointers into a specialized version of __arm_v7s_unmap:
> >> 
> >> WARNING: modpost: vmlinux: section mismatch in reference: __arm_v7s_unmap+0x2cc (section: .text) -> dummy_tlb_add_page (section: .init.text)
> >> 
> >> From what I can tell, the transformation is correct, as this
> >> is only called when __arm_v7s_unmap() is called from
> >> arm_v7s_do_selftests(), which is also __init.
> >> 
> >> I have not come up with a good workaround, so this simply marks
> >> dummy_tlb_add_page() 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!
> >
> > Can we mark the dummy_* functions as 'noinline' instead? We shouldn't
> > have to keep the selftest code kicking around in memory after boot.
> 
> I think that would work as well, but I'd have to test it properly,
> as the gcc behavior was already not what I had expected.
> 
> Another option may be to take this a bit further and do the
> same for the arm_v7s selftest that Mostafa did in the lpae
> selftest with 7e06063a43d3 ("iommu/io-pgtable-arm-selftests:
> Use KUnit") and a3c24b6d7cd6 ("iommu/io-pgtable-arm-selftests:
> Modularize the test").
> 
> I think that would be the most logical step, but it's also
> beyond what I can do as a simple build fix.

tbh, I'm happy to take the noinline variant as a quick hack if it works.

Will

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.