linux-next: build failure after merge of the mm-nonmm-unstable tree

linux-next: build failure after merge of the mm-nonmm-unstable tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]

Hi all,

After merging the mm-nonmm-unstable tree, today's linux-next build
(x86_64 allmodconfig) failed like this:

kernel/kexec_core.c: In function 'kernel_kexec':
kernel/kexec_core.c:1138:2: error: label 'Resume_console' defined but not used [-Werror=unused-label]
 1138 |  Resume_console:
      |  ^~~~~~~~~~~~~~
cc1: all warnings being treated as errors

Caused by commit

  fbb5aa47e7b0 ("kexec_core: fix error code path in the KEXEC_JUMP flow")

I have applied the following fix patch.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 11 Jul 2025 10:35:39 +1000
Subject: [PATCH] fix up for "kexec_core: fix error code path in the KEXEC_JUMP flow"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 kernel/kexec_core.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 842611c0b51a..351cd7d76dfa 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -1135,7 +1135,6 @@ int kernel_kexec(void)
 		dpm_resume_start(PMSG_RESTORE);
  Resume_devices:
 		dpm_resume_end(PMSG_RESTORE);
- Resume_console:
 		console_resume_all();
 		thaw_processes();
  Restore_console:
-- 
2.50.0

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: build failure after merge of the mm-nonmm-unstable tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]

Hi all,

After merging the mm-nonmm-unstable tree, today's linux-next build
(x86_64 allmodconfig) failed like this:

In file included from samples/vfs/test-list-all-mounts.c:11:
samples/vfs/../../tools/testing/selftests/pidfd/pidfd.h:28:10: fatal error: kselftest.h: No such file or directory
   28 | #include "kselftest.h"
      |          ^~~~~~~~~~~~~

Caused by commit

  df420f0a4946 ("selftests: replace relative includes with non-relative for kselftest.h and kselftest_harness.h")

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: build failure after merge of the mm-nonmm-unstable tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

Hi all,

After merging the mm-nonmm-unstable tree, today's linux-next build
(x86 allmodconfig) failed like this:

In file included from /tmp/next/build/samples/vfs/test-list-all-mounts.c:11:
/tmp/next/build/samples/vfs/../../tools/testing/selftests/pidfd/pidfd.h:28:10: fatal error: kselftest.h: No such file or directory
   28 | #include "kselftest.h"
      |          ^~~~~~~~~~~~~
compilation terminated.
make[5]: *** [/tmp/next/build/scripts/Makefile.userprogs:29: samples/vfs/test-list-all-mounts] Error 1
make[4]: *** [/tmp/next/build/scripts/Makefile.build:556: samples/vfs] Error 2
make[4]: *** Waiting for unfinished jobs....
make[3]: *** [/tmp/next/build/scripts/Makefile.build:556: samples] Error 2
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [/tmp/next/build/Makefile:2010: .] Error 2
make[1]: *** [/tmp/next/build/Makefile:248: __sub-make] Error 2
make: *** [Makefile:248: __sub-make] Error 2

Caused by commit

  f46a41a153634 (selftests: complete kselftest include centralization)

I have reverted that commit for today.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the mm-nonmm-unstable tree

[Andrew Morton]

On Fri, 17 Oct 2025 14:25:52 +0100 Mark Brown <broonie@kernel.org> wrote:

> After merging the mm-nonmm-unstable tree, today's linux-next build
> (x86 allmodconfig) failed like this:
> 
> In file included from /tmp/next/build/samples/vfs/test-list-all-mounts.c:11:
> /tmp/next/build/samples/vfs/../../tools/testing/selftests/pidfd/pidfd.h:28:10: fatal error: kselftest.h: No such file or directory
>    28 | #include "kselftest.h"
>       |          ^~~~~~~~~~~~~

Well that:

#include "../../tools/testing/selftests/pidfd/pidfd.h"

was a strange thing to do.

I'll toss this on top:

--- a/samples/vfs/Makefile~selftests-complete-kselftest-include-centralization-fix
+++ a/samples/vfs/Makefile
@@ -1,4 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0-only
 userprogs-always-y += test-fsmount test-statx mountinfo test-list-all-mounts
 
+CFLAGS += -I../../tools/testing/selftests
+
 userccflags += -I usr/include
_

but there's probably a better way...

linux-next: build failure after merge of the mm-nonmm-unstable tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3360 bytes --]

Hi all,

After merging the mm-nonmm-unstable tree, today's linux-next build
(powerpc ppc64_defconfig) failed like this:

In file included from drivers/of/fdt.c:28:
include/linux/kexec_handover.h:99:7: warning: no previous prototype for 'kho_alloc_preserve' [-Wmissing-prototypes]
   99 | void *kho_alloc_preserve(size_t size)
      |       ^~~~~~~~~~~~~~~~~~
include/linux/kexec_handover.h:104:6: warning: no previous prototype for 'kho_unpreserve_free' [-Wmissing-prototypes]
  104 | void kho_unpreserve_free(void *mem) { }
      |      ^~~~~~~~~~~~~~~~~~~
include/linux/kexec_handover.h:105:6: warning: no previous prototype for 'kho_restore_free' [-Wmissing-prototypes]
  105 | void kho_restore_free(void *mem) { }
      |      ^~~~~~~~~~~~~~~~
In file included from mm/mm_init.c:34:
include/linux/kexec_handover.h:99:7: warning: no previous prototype for 'kho_alloc_preserve' [-Wmissing-prototypes]
   99 | void *kho_alloc_preserve(size_t size)
      |       ^~~~~~~~~~~~~~~~~~
include/linux/kexec_handover.h:104:6: warning: no previous prototype for 'kho_unpreserve_free' [-Wmissing-prototypes]
  104 | void kho_unpreserve_free(void *mem) { }
      |      ^~~~~~~~~~~~~~~~~~~
include/linux/kexec_handover.h:105:6: warning: no previous prototype for 'kho_restore_free' [-Wmissing-prototypes]
  105 | void kho_restore_free(void *mem) { }
      |      ^~~~~~~~~~~~~~~~
ld: drivers/of/fdt.o: in function `kho_alloc_preserve':
fdt.c:(.text+0x9c0): multiple definition of `kho_alloc_preserve'; mm/mm_init.o:mm_init.c:(.text+0x230): first defined here
ld: drivers/of/fdt.o: in function `kho_unpreserve_free':
fdt.c:(.text+0x9d0): multiple definition of `kho_unpreserve_free'; mm/mm_init.o:mm_init.c:(.text+0x240): first defined here
ld: drivers/of/fdt.o: in function `kho_restore_free':
fdt.c:(.text+0x9e0): multiple definition of `kho_restore_free'; mm/mm_init.o:mm_init.c:(.text+0x250): first defined here

Caused by commit

  722b2ce4a04f ("kho: introduce high-level memory allocation API")

I have applied the following fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 17 Nov 2025 09:29:44 +1100
Subject: [PATCH] fix up for "kho: introduce high-level memory allocation API"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/linux/kexec_handover.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/kexec_handover.h b/include/linux/kexec_handover.h
index 6dd0dcdf0ec1..5f7b9de97e8d 100644
--- a/include/linux/kexec_handover.h
+++ b/include/linux/kexec_handover.h
@@ -96,13 +96,13 @@ static inline int kho_preserve_vmalloc(void *ptr,
 
 static inline void kho_unpreserve_vmalloc(struct kho_vmalloc *preservation) { }
 
-void *kho_alloc_preserve(size_t size)
+static inline void *kho_alloc_preserve(size_t size)
 {
 	return ERR_PTR(-EOPNOTSUPP);
 }
 
-void kho_unpreserve_free(void *mem) { }
-void kho_restore_free(void *mem) { }
+static inline void kho_unpreserve_free(void *mem) { }
+static inline void kho_restore_free(void *mem) { }
 
 static inline struct folio *kho_restore_folio(phys_addr_t phys)
 {
-- 
2.51.1

As a review nitpicks on that commit:  please do not do unrelated
formatting changes.  Also, there was not real reason for moving the
types.h include.
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: build failure after merge of the mm-nonmm-unstable tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]

Hi all,

After merging the mm-nonmm-unstable tree, today's linux-next build
(x86_64 allmodconfig) failed like this:

error[E0425]: cannot find function `rb_first` in crate `bindings`
   --> rust/kernel/rbtree.rs:209:42
    |
209 |                 next: unsafe { bindings::rb_first(&self.root) },
    |                                          ^^^^^^^^ not found in `bindings`

error[E0425]: cannot find function `rb_first` in crate `bindings`
   --> rust/kernel/rbtree.rs:224:42
    |
224 |                 next: unsafe { bindings::rb_first(from_mut(&mut self.root)) },
    |                                          ^^^^^^^^ not found in `bindings`

error[E0425]: cannot find function `rb_first` in crate `bindings`
   --> rust/kernel/rbtree.rs:249:42
    |
249 |         let current = unsafe { bindings::rb_first(root) };
    |                                          ^^^^^^^^ not found in `bindings`

error[E0425]: cannot find function `rb_last` in crate `bindings`
     --> rust/kernel/rbtree.rs:264:42
      |
264   |         let current = unsafe { bindings::rb_last(root) };
      |                                          ^^^^^^^ help: a function with a similar name exists: `sg_last`
      |
     ::: rust/bindings/bindings_generated.rs:90155:5
      |
90155 |     pub fn sg_last(s: *mut scatterlist, arg1: ffi::c_uint) -> *mut scatterlist;
      |     --------------------------------------------------------------------------- similarly named function `sg_last` defined here

error: aborting due to 4 previous errors

For more information about this error, try `rustc --explain E0425`.

Caused by commit

  84aa8c5fc414 ("rbtree: inline rb_first()")

I have reverted that commit and the following one for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the mm-nonmm-unstable tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2016 bytes --]

Hi all,

On Mon, 17 Nov 2025 10:23:10 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the mm-nonmm-unstable tree, today's linux-next build
> (x86_64 allmodconfig) failed like this:
> 
> error[E0425]: cannot find function `rb_first` in crate `bindings`
>    --> rust/kernel/rbtree.rs:209:42  
>     |
> 209 |                 next: unsafe { bindings::rb_first(&self.root) },
>     |                                          ^^^^^^^^ not found in `bindings`
> 
> error[E0425]: cannot find function `rb_first` in crate `bindings`
>    --> rust/kernel/rbtree.rs:224:42  
>     |
> 224 |                 next: unsafe { bindings::rb_first(from_mut(&mut self.root)) },
>     |                                          ^^^^^^^^ not found in `bindings`
> 
> error[E0425]: cannot find function `rb_first` in crate `bindings`
>    --> rust/kernel/rbtree.rs:249:42  
>     |
> 249 |         let current = unsafe { bindings::rb_first(root) };
>     |                                          ^^^^^^^^ not found in `bindings`
> 
> error[E0425]: cannot find function `rb_last` in crate `bindings`
>      --> rust/kernel/rbtree.rs:264:42  
>       |
> 264   |         let current = unsafe { bindings::rb_last(root) };
>       |                                          ^^^^^^^ help: a function with a similar name exists: `sg_last`
>       |
>      ::: rust/bindings/bindings_generated.rs:90155:5
>       |
> 90155 |     pub fn sg_last(s: *mut scatterlist, arg1: ffi::c_uint) -> *mut scatterlist;
>       |     --------------------------------------------------------------------------- similarly named function `sg_last` defined here
> 
> error: aborting due to 4 previous errors
> 
> For more information about this error, try `rustc --explain E0425`.
> 
> Caused by commit
> 
>   84aa8c5fc414 ("rbtree: inline rb_first()")
> 
> I have reverted that commit and the following one for today.

I am still reverting those commits.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the mm-nonmm-unstable tree

[Andrew Morton]

On Thu, 20 Nov 2025 10:14:40 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> On Mon, 17 Nov 2025 10:23:10 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the mm-nonmm-unstable tree, today's linux-next build
> > (x86_64 allmodconfig) failed like this:
> > 
> > error[E0425]: cannot find function `rb_first` in crate `bindings`
> >    --> rust/kernel/rbtree.rs:209:42  
> >     |
> > 209 |                 next: unsafe { bindings::rb_first(&self.root) },
> >     |                                          ^^^^^^^^ not found in `bindings`
> > 
> > error[E0425]: cannot find function `rb_first` in crate `bindings`
> >    --> rust/kernel/rbtree.rs:224:42  
> >     |
> > 224 |                 next: unsafe { bindings::rb_first(from_mut(&mut self.root)) },
> >     |                                          ^^^^^^^^ not found in `bindings`
> > 
> > error[E0425]: cannot find function `rb_first` in crate `bindings`
> >    --> rust/kernel/rbtree.rs:249:42  
> >     |
> > 249 |         let current = unsafe { bindings::rb_first(root) };
> >     |                                          ^^^^^^^^ not found in `bindings`
> > 
> > error[E0425]: cannot find function `rb_last` in crate `bindings`
> >      --> rust/kernel/rbtree.rs:264:42  
> >       |
> > 264   |         let current = unsafe { bindings::rb_last(root) };
> >       |                                          ^^^^^^^ help: a function with a similar name exists: `sg_last`
> >       |
> >      ::: rust/bindings/bindings_generated.rs:90155:5
> >       |
> > 90155 |     pub fn sg_last(s: *mut scatterlist, arg1: ffi::c_uint) -> *mut scatterlist;
> >       |     --------------------------------------------------------------------------- similarly named function `sg_last` defined here
> > 
> > error: aborting due to 4 previous errors
> > 
> > For more information about this error, try `rustc --explain E0425`.
> > 
> > Caused by commit
> > 
> >   84aa8c5fc414 ("rbtree: inline rb_first()")
> > 
> > I have reverted that commit and the following one for today.
> 
> I am still reverting those commits.

Thanks, I'll disable them for now.

Alice, can you please help us with a fix?  Simple patch follows:



--- a/include/linux/rbtree.h~rbtree-inline-rb_first
+++ a/include/linux/rbtree.h
@@ -43,7 +43,21 @@ extern void rb_erase(struct rb_node *, s
 /* Find logical next and previous nodes in a tree */
 extern struct rb_node *rb_next(const struct rb_node *);
 extern struct rb_node *rb_prev(const struct rb_node *);
-extern struct rb_node *rb_first(const struct rb_root *);
+
+/*
+ * This function returns the first node (in sort order) of the tree.
+ */
+static inline struct rb_node *rb_first(const struct rb_root *root)
+{
+	struct rb_node	*n;
+
+	n = root->rb_node;
+	if (!n)
+		return NULL;
+	while (n->rb_left)
+		n = n->rb_left;
+	return n;
+}
 extern struct rb_node *rb_last(const struct rb_root *);
 
 /* Postorder iteration - always visit the parent after its children */
--- a/lib/rbtree.c~rbtree-inline-rb_first
+++ a/lib/rbtree.c
@@ -460,22 +460,6 @@ void __rb_insert_augmented(struct rb_nod
 }
 EXPORT_SYMBOL(__rb_insert_augmented);
 
-/*
- * This function returns the first node (in sort order) of the tree.
- */
-struct rb_node *rb_first(const struct rb_root *root)
-{
-	struct rb_node	*n;
-
-	n = root->rb_node;
-	if (!n)
-		return NULL;
-	while (n->rb_left)
-		n = n->rb_left;
-	return n;
-}
-EXPORT_SYMBOL(rb_first);
-
 struct rb_node *rb_last(const struct rb_root *root)
 {
 	struct rb_node	*n;
_

Re: linux-next: build failure after merge of the mm-nonmm-unstable tree

[Miguel Ojeda]

On Wed, 19 Nov 2025 15:48:24 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> Thanks, I'll disable them for now.
>
> Alice, can you please help us with a fix?  Simple patch follows:

Something like this should work (I would suggest adding each helper into
the right commit that performs each move to the header):

diff --git a/rust/helpers/rbtree.c b/rust/helpers/rbtree.c
index 6d404b84a9b5..2a0eabbb4160 100644
--- a/rust/helpers/rbtree.c
+++ b/rust/helpers/rbtree.c
@@ -7,3 +7,13 @@ void rust_helper_rb_link_node(struct rb_node *node, struct rb_node *parent,
 {
        rb_link_node(node, parent, rb_link);
 }
+
+struct rb_node *rust_helper_rb_first(const struct rb_root *root)
+{
+       return rb_first(root);
+}
+
+struct rb_node *rust_helper_rb_last(const struct rb_root *root)
+{
+       return rb_last(root);
+}

Cheers,
Miguel

Re: linux-next: build failure after merge of the mm-nonmm-unstable tree

[Alice Ryhl]

On Wed, Nov 19, 2025 at 03:48:24PM -0800, Andrew Morton wrote:
> On Thu, 20 Nov 2025 10:14:40 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi all,
> > 
> > On Mon, 17 Nov 2025 10:23:10 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > After merging the mm-nonmm-unstable tree, today's linux-next build
> > > (x86_64 allmodconfig) failed like this:
> > > 
> > > error[E0425]: cannot find function `rb_first` in crate `bindings`
> > >    --> rust/kernel/rbtree.rs:209:42  
> > >     |
> > > 209 |                 next: unsafe { bindings::rb_first(&self.root) },
> > >     |                                          ^^^^^^^^ not found in `bindings`
> > > 
> > > error[E0425]: cannot find function `rb_first` in crate `bindings`
> > >    --> rust/kernel/rbtree.rs:224:42  
> > >     |
> > > 224 |                 next: unsafe { bindings::rb_first(from_mut(&mut self.root)) },
> > >     |                                          ^^^^^^^^ not found in `bindings`
> > > 
> > > error[E0425]: cannot find function `rb_first` in crate `bindings`
> > >    --> rust/kernel/rbtree.rs:249:42  
> > >     |
> > > 249 |         let current = unsafe { bindings::rb_first(root) };
> > >     |                                          ^^^^^^^^ not found in `bindings`
> > > 
> > > error[E0425]: cannot find function `rb_last` in crate `bindings`
> > >      --> rust/kernel/rbtree.rs:264:42  
> > >       |
> > > 264   |         let current = unsafe { bindings::rb_last(root) };
> > >       |                                          ^^^^^^^ help: a function with a similar name exists: `sg_last`
> > >       |
> > >      ::: rust/bindings/bindings_generated.rs:90155:5
> > >       |
> > > 90155 |     pub fn sg_last(s: *mut scatterlist, arg1: ffi::c_uint) -> *mut scatterlist;
> > >       |     --------------------------------------------------------------------------- similarly named function `sg_last` defined here
> > > 
> > > error: aborting due to 4 previous errors
> > > 
> > > For more information about this error, try `rustc --explain E0425`.
> > > 
> > > Caused by commit
> > > 
> > >   84aa8c5fc414 ("rbtree: inline rb_first()")
> > > 
> > > I have reverted that commit and the following one for today.
> > 
> > I am still reverting those commits.
> 
> Thanks, I'll disable them for now.
> 
> Alice, can you please help us with a fix?  Simple patch follows:

The diff Miguel shared should fix this issue. Let me know if you need a
real patch.

Alice

linux-next: build failure after merge of the mm-nonmm-unstable tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 439 bytes --]

Hi all,

After merging the mm-nonmm-unstable tree, today's linux-next build
(x86_64 allmodconfig) failed like this:

x86_64-linux-gnu-ld: error: unplaced orphan section `__bug_table' from `arch/x86/boot/compressed/sev-handle-vc.o'

Caused by commit

  e7980cd46155 ("atomic: add alignment check to instrumented atomic operations")

I have reverted that commit and the following one for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the mm-nonmm-unstable tree

[Finn Thain]

On Thu, 18 Dec 2025, Stephen Rothwell wrote:

> After merging the mm-nonmm-unstable tree, today's linux-next build
> (x86_64 allmodconfig) failed like this:
> 
> x86_64-linux-gnu-ld: error: unplaced orphan section `__bug_table' from `arch/x86/boot/compressed/sev-handle-vc.o'
> 

I found that I could reproduce the same build failure after applying 
Peter's patch to v6.19-rc1. So it's not confined to linux-next. I used 
allnoconfig with CONFIG_LD_ORPHAN_WARN_LEVEL=error and 
CONFIG_AMD_MEM_ENCRYPT=y because allmodconfig takes forever to build.

The patch in question is this one:
https://lore.kernel.org/lkml/0c18fd08ef19497768070783da28086e01d11a00.1765866665.git.fthain@linux-m68k.org/

I may have found a solution for the problem, but I don't understand this 
code, so I've Cc'd Ard et al. I don't know whether the __bug_table section 
is relevant to sev-handle-vc.c. If that section is not desired, I propose 
to make this change to Peter's patch --

diff --git a/include/linux/instrumented.h b/include/linux/instrumented.h
index 402a999a0d6b..d39d89206561 100644
--- a/include/linux/instrumented.h
+++ b/include/linux/instrumented.h
@@ -68,7 +68,9 @@ static __always_inline void instrument_atomic_read(const volatile void *v, size_
 {
 	kasan_check_read(v, size);
 	kcsan_check_atomic_read(v, size);
+#ifndef __DISABLE_EXPORTS
 	WARN_ON_ONCE(IS_ENABLED(CONFIG_DEBUG_ATOMIC) && ((unsigned long)v & (size - 1)));
+#endif
 }
 
 /**
@@ -83,7 +85,9 @@ static __always_inline void instrument_atomic_write(const volatile void *v, size
 {
 	kasan_check_write(v, size);
 	kcsan_check_atomic_write(v, size);
+#ifndef __DISABLE_EXPORTS
 	WARN_ON_ONCE(IS_ENABLED(CONFIG_DEBUG_ATOMIC) && ((unsigned long)v & (size - 1)));
+#endif
 }
 
 /**
@@ -98,7 +102,9 @@ static __always_inline void instrument_atomic_read_write(const volatile void *v,
 {
 	kasan_check_write(v, size);
 	kcsan_check_atomic_read_write(v, size);
+#ifndef __DISABLE_EXPORTS
 	WARN_ON_ONCE(IS_ENABLED(CONFIG_DEBUG_ATOMIC) && ((unsigned long)v & (size - 1)));
+#endif
 }
 
 /**


The next patch in the series needs a similar change, which I've also 
pushed to my github repo at
https://github.com/fthain/linux/commits/atomic_t

Re: linux-next: build failure after merge of the mm-nonmm-unstable tree

[Sasha Levin]

On Sun, Dec 21, 2025 at 01:58:17PM +1100, Finn Thain wrote:
>
>On Thu, 18 Dec 2025, Stephen Rothwell wrote:
>
>> After merging the mm-nonmm-unstable tree, today's linux-next build
>> (x86_64 allmodconfig) failed like this:
>>
>> x86_64-linux-gnu-ld: error: unplaced orphan section `__bug_table' from `arch/x86/boot/compressed/sev-handle-vc.o'
>>
>
>I found that I could reproduce the same build failure after applying
>Peter's patch to v6.19-rc1. So it's not confined to linux-next. I used
>allnoconfig with CONFIG_LD_ORPHAN_WARN_LEVEL=error and
>CONFIG_AMD_MEM_ENCRYPT=y because allmodconfig takes forever to build.
>
>The patch in question is this one:
>https://lore.kernel.org/lkml/0c18fd08ef19497768070783da28086e01d11a00.1765866665.git.fthain@linux-m68k.org/
>
>I may have found a solution for the problem, but I don't understand this
>code, so I've Cc'd Ard et al. I don't know whether the __bug_table section
>is relevant to sev-handle-vc.c. If that section is not desired, I propose
>to make this change to Peter's patch --

I think that the issue here is that we're trying to use WARN in the early boot
context. We should probably add CONFIG_DEBUG_ATOMIC to the list of configs we
disable for that:

diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
index 4f86c5903e03..bb36dcef7d08 100644
--- a/arch/x86/boot/compressed/misc.h
+++ b/arch/x86/boot/compressed/misc.h
@@ -14,6 +14,7 @@
  #undef CONFIG_ARCH_HAS_LAZY_MMU_MODE
  #undef CONFIG_KASAN
  #undef CONFIG_KASAN_GENERIC
+#undef CONFIG_DEBUG_ATOMIC

-- 
Thanks,
Sasha

Re: linux-next: build failure after merge of the mm-nonmm-unstable tree

[Finn Thain]

On Fri, 26 Dec 2025, Sasha Levin wrote:

> On Sun, Dec 21, 2025 at 01:58:17PM +1100, Finn Thain wrote:
> >
> >On Thu, 18 Dec 2025, Stephen Rothwell wrote:
> >
> >> After merging the mm-nonmm-unstable tree, today's linux-next build
> >> (x86_64 allmodconfig) failed like this:
> >>
> >> x86_64-linux-gnu-ld: error: unplaced orphan section `__bug_table' from
> >> `arch/x86/boot/compressed/sev-handle-vc.o'
> >>
> >
> >I found that I could reproduce the same build failure after applying
> >Peter's patch to v6.19-rc1. So it's not confined to linux-next. I used
> >allnoconfig with CONFIG_LD_ORPHAN_WARN_LEVEL=error and
> >CONFIG_AMD_MEM_ENCRYPT=y because allmodconfig takes forever to build.
> >
> >The patch in question is this one:
> >https://lore.kernel.org/lkml/0c18fd08ef19497768070783da28086e01d11a00.1765866665.git.fthain@linux-m68k.org/
> >
> >I may have found a solution for the problem, but I don't understand this
> >code, so I've Cc'd Ard et al. I don't know whether the __bug_table section
> >is relevant to sev-handle-vc.c. If that section is not desired, I propose
> >to make this change to Peter's patch --
> 
> I think that the issue here is that we're trying to use WARN in the 
> early boot context. We should probably add CONFIG_DEBUG_ATOMIC to the 
> list of configs we disable for that:
> 
> diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
> index 4f86c5903e03..bb36dcef7d08 100644
> --- a/arch/x86/boot/compressed/misc.h
> +++ b/arch/x86/boot/compressed/misc.h
> @@ -14,6 +14,7 @@
>  #undef CONFIG_ARCH_HAS_LAZY_MMU_MODE
>  #undef CONFIG_KASAN
>  #undef CONFIG_KASAN_GENERIC
> +#undef CONFIG_DEBUG_ATOMIC
> 

Thanks for sending that suggestion. It does fix the problem on x86_64. 
However, the problem also affects arm, arm64, riscv, riscv64 and 
loongarch. The fix I proposed (i.e. test __DISABLE_EXPORTS) works on all 
of the affected architectures because 
drivers/firmware/efi/libstub/Makefile puts -D__DISABLE_EXPORTS in CFLAGS, 
just as arch/x86/boot/compressed/Makefile does.

AFAICT, when I put -UCONFIG_DEBUG_ATOMIC in CFLAGS, it doesn't override 
that macro definition autoconf.h. And there is no equivalent of 
arch/x86/boot/compressed/misc.h in drivers/firmware/efi/libstub so I can't 
simply add #undef CONFIG_DEBUG_ATOMIC there.

If __DISABLE_EXPORTS is not the appropriate macro for this purpose, then 
we need a new macro (e.g. __DISABLE_BUG_TABLE) or else we need a new 
header, to be included by some unknown set of .c files (that might 
accidentally #include bug.h) so that this new header could do #undef 
CONFIG_DEBUG_ATOMIC. My inclination is to implement -D__DISABLE_BUG_TABLE 
but I'm open to suggestions.

Re: linux-next: build failure after merge of the mm-nonmm-unstable tree

[Finn Thain]

On Mon, 29 Dec 2025, Finn Thain wrote:

> On Fri, 26 Dec 2025, Sasha Levin wrote:
> 
> > On Sun, Dec 21, 2025 at 01:58:17PM +1100, Finn Thain wrote:
> > >
> > >On Thu, 18 Dec 2025, Stephen Rothwell wrote:
> > >
> > >> After merging the mm-nonmm-unstable tree, today's linux-next build 
> > >> (x86_64 allmodconfig) failed like this:
> > >>
> > >> x86_64-linux-gnu-ld: error: unplaced orphan section `__bug_table' from
> > >> `arch/x86/boot/compressed/sev-handle-vc.o'
> > >>
> > >
> > >I found that I could reproduce the same build failure after applying 
> > >Peter's patch to v6.19-rc1. So it's not confined to linux-next. I 
> > >used allnoconfig with CONFIG_LD_ORPHAN_WARN_LEVEL=error and 
> > >CONFIG_AMD_MEM_ENCRYPT=y because allmodconfig takes forever to build.
> > >
> > >The patch in question is this one: 
> > >https://lore.kernel.org/lkml/0c18fd08ef19497768070783da28086e01d11a00.1765866665.git.fthain@linux-m68k.org/
> > >
> > >I may have found a solution for the problem, but I don't understand 
> > >this code, so I've Cc'd Ard et al. I don't know whether the 
> > >__bug_table section is relevant to sev-handle-vc.c. If that section 
> > >is not desired, I propose to make this change to Peter's patch --
> > 
> > I think that the issue here is that we're trying to use WARN in the 
> > early boot context. We should probably add CONFIG_DEBUG_ATOMIC to the 
> > list of configs we disable for that:
> > 
> > diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
> > index 4f86c5903e03..bb36dcef7d08 100644
> > --- a/arch/x86/boot/compressed/misc.h
> > +++ b/arch/x86/boot/compressed/misc.h
> > @@ -14,6 +14,7 @@
> >  #undef CONFIG_ARCH_HAS_LAZY_MMU_MODE
> >  #undef CONFIG_KASAN
> >  #undef CONFIG_KASAN_GENERIC
> > +#undef CONFIG_DEBUG_ATOMIC
> > 
> 
> Thanks for sending that suggestion. It does fix the problem on x86_64. 
> However, the problem also affects arm, arm64, riscv, riscv64 and 
> loongarch. The fix I proposed (i.e. test __DISABLE_EXPORTS) works on all 
> of the affected architectures because 
> drivers/firmware/efi/libstub/Makefile puts -D__DISABLE_EXPORTS in 
> CFLAGS, just as arch/x86/boot/compressed/Makefile does.
> 
> AFAICT, when I put -UCONFIG_DEBUG_ATOMIC in CFLAGS, it doesn't override 
> that macro definition autoconf.h. And there is no equivalent of 
> arch/x86/boot/compressed/misc.h in drivers/firmware/efi/libstub so I 
> can't simply add #undef CONFIG_DEBUG_ATOMIC there.
> 

I'd better correct myself. That header does actually exist:
drivers/firmware/efi/libstub/efistub.h
I overlooked it somehow.

> If __DISABLE_EXPORTS is not the appropriate macro for this purpose, then 
> we need a new macro (e.g. __DISABLE_BUG_TABLE) or else we need a new 
> header, to be included by some unknown set of .c files (that might 
> accidentally #include bug.h) so that this new header could do #undef 
> CONFIG_DEBUG_ATOMIC. My inclination is to implement 
> -D__DISABLE_BUG_TABLE but I'm open to suggestions.
> 

After I sent patches using -D__DISABLE_BUG_TABLE, I figured out that your 
#undef suggestion has some appeal: by confining the preprocessor tricks to 
drivers/firmware/efi/libstub/, we might avoid spreading them across 
include/linux/ which has a certain tidyness to it.

The only problem is fragility. The ordering of #include and #undef 
directives is critical and complicated. I can't seem to get it right.
The following patch produces a build failure.

diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
index fd855e32c9b9..8442eebaada1 100644
--- a/arch/x86/boot/compressed/misc.h
+++ b/arch/x86/boot/compressed/misc.h
@@ -8,6 +8,7 @@
  * we just keep it from happening. (This list needs to be extended when new
  * paravirt and debugging variants are added.)
  */
+#include <generated/autoconf.h>
 #undef CONFIG_PARAVIRT
 #undef CONFIG_PARAVIRT_XXL
 #undef CONFIG_PARAVIRT_SPINLOCKS


Problem is, you can't do #undef unless you know that #define has already 
taken place, and you can't #define again if #undef has already taken 
place...

Anyway, that's just BTW: I don't feel any need to revise the patches I 
sent.

Re: linux-next: build failure after merge of the mm-nonmm-unstable tree

[Randy Dunlap]

On 1/1/26 1:21 AM, Finn Thain wrote:
> 
> On Mon, 29 Dec 2025, Finn Thain wrote:
> 
>> On Fri, 26 Dec 2025, Sasha Levin wrote:
>>
>>> On Sun, Dec 21, 2025 at 01:58:17PM +1100, Finn Thain wrote:
>>>>
>>>> On Thu, 18 Dec 2025, Stephen Rothwell wrote:
>>>>
>>>>> After merging the mm-nonmm-unstable tree, today's linux-next build 
>>>>> (x86_64 allmodconfig) failed like this:
>>>>>
>>>>> x86_64-linux-gnu-ld: error: unplaced orphan section `__bug_table' from
>>>>> `arch/x86/boot/compressed/sev-handle-vc.o'
>>>>>
>>>>
>>>> I found that I could reproduce the same build failure after applying 
>>>> Peter's patch to v6.19-rc1. So it's not confined to linux-next. I 
>>>> used allnoconfig with CONFIG_LD_ORPHAN_WARN_LEVEL=error and 
>>>> CONFIG_AMD_MEM_ENCRYPT=y because allmodconfig takes forever to build.
>>>>
>>>> The patch in question is this one: 
>>>> https://lore.kernel.org/lkml/0c18fd08ef19497768070783da28086e01d11a00.1765866665.git.fthain@linux-m68k.org/
>>>>
>>>> I may have found a solution for the problem, but I don't understand 
>>>> this code, so I've Cc'd Ard et al. I don't know whether the 
>>>> __bug_table section is relevant to sev-handle-vc.c. If that section 
>>>> is not desired, I propose to make this change to Peter's patch --
>>>
>>> I think that the issue here is that we're trying to use WARN in the 
>>> early boot context. We should probably add CONFIG_DEBUG_ATOMIC to the 
>>> list of configs we disable for that:
>>>
>>> diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
>>> index 4f86c5903e03..bb36dcef7d08 100644
>>> --- a/arch/x86/boot/compressed/misc.h
>>> +++ b/arch/x86/boot/compressed/misc.h
>>> @@ -14,6 +14,7 @@
>>>  #undef CONFIG_ARCH_HAS_LAZY_MMU_MODE
>>>  #undef CONFIG_KASAN
>>>  #undef CONFIG_KASAN_GENERIC
>>> +#undef CONFIG_DEBUG_ATOMIC
>>>
>>
>> Thanks for sending that suggestion. It does fix the problem on x86_64. 
>> However, the problem also affects arm, arm64, riscv, riscv64 and 
>> loongarch. The fix I proposed (i.e. test __DISABLE_EXPORTS) works on all 
>> of the affected architectures because 
>> drivers/firmware/efi/libstub/Makefile puts -D__DISABLE_EXPORTS in 
>> CFLAGS, just as arch/x86/boot/compressed/Makefile does.
>>
>> AFAICT, when I put -UCONFIG_DEBUG_ATOMIC in CFLAGS, it doesn't override 
>> that macro definition autoconf.h. And there is no equivalent of 
>> arch/x86/boot/compressed/misc.h in drivers/firmware/efi/libstub so I 
>> can't simply add #undef CONFIG_DEBUG_ATOMIC there.
>>
> 
> I'd better correct myself. That header does actually exist:
> drivers/firmware/efi/libstub/efistub.h
> I overlooked it somehow.
> 
>> If __DISABLE_EXPORTS is not the appropriate macro for this purpose, then 
>> we need a new macro (e.g. __DISABLE_BUG_TABLE) or else we need a new 
>> header, to be included by some unknown set of .c files (that might 
>> accidentally #include bug.h) so that this new header could do #undef 
>> CONFIG_DEBUG_ATOMIC. My inclination is to implement 
>> -D__DISABLE_BUG_TABLE but I'm open to suggestions.
>>
> 
> After I sent patches using -D__DISABLE_BUG_TABLE, I figured out that your 
> #undef suggestion has some appeal: by confining the preprocessor tricks to 
> drivers/firmware/efi/libstub/, we might avoid spreading them across 
> include/linux/ which has a certain tidyness to it.
> 
> The only problem is fragility. The ordering of #include and #undef 
> directives is critical and complicated. I can't seem to get it right.
> The following patch produces a build failure.
> 
> diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
> index fd855e32c9b9..8442eebaada1 100644
> --- a/arch/x86/boot/compressed/misc.h
> +++ b/arch/x86/boot/compressed/misc.h
> @@ -8,6 +8,7 @@
>   * we just keep it from happening. (This list needs to be extended when new
>   * paravirt and debugging variants are added.)
>   */
> +#include <generated/autoconf.h>
>  #undef CONFIG_PARAVIRT
>  #undef CONFIG_PARAVIRT_XXL
>  #undef CONFIG_PARAVIRT_SPINLOCKS
> 
> 
> Problem is, you can't do #undef unless you know that #define has already 
> taken place, and you can't #define again if #undef has already taken 
> place...
> 
> Anyway, that's just BTW: I don't feel any need to revise the patches I 
> sent.
> 

Hi,
You mean something more than

+#include <generated/autoconf.h>
+#ifdef CONFIG_PARAVIRT
 #undef CONFIG_PARAVIRT
+#endif
+#ifdef CONFIG_PARAVIRT_XXL
 #undef CONFIG_PARAVIRT_XXL
+#endif
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
 #undef CONFIG_PARAVIRT_SPINLOCKS
+#endif

-- 
~Randy

Re: linux-next: build failure after merge of the mm-nonmm-unstable tree

[Finn Thain]

On Thu, 1 Jan 2026, Randy Dunlap wrote:

> > The following patch produces a build failure.
> > 
> > diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
> > index fd855e32c9b9..8442eebaada1 100644
> > --- a/arch/x86/boot/compressed/misc.h
> > +++ b/arch/x86/boot/compressed/misc.h
> > @@ -8,6 +8,7 @@
> >   * we just keep it from happening. (This list needs to be extended when new
> >   * paravirt and debugging variants are added.)
> >   */
> > +#include <generated/autoconf.h>
> >  #undef CONFIG_PARAVIRT
> >  #undef CONFIG_PARAVIRT_XXL
> >  #undef CONFIG_PARAVIRT_SPINLOCKS
> > 
> > 
> > Problem is, you can't do #undef unless you know that #define has already 
> > taken place, and you can't #define again if #undef has already taken 
> > place...
> > 
> > Anyway, that's just BTW: I don't feel any need to revise the patches I 
> > sent.
> > 
> 
> Hi,
> You mean something more than
> 
> +#include <generated/autoconf.h>
> +#ifdef CONFIG_PARAVIRT
>  #undef CONFIG_PARAVIRT
> +#endif
> +#ifdef CONFIG_PARAVIRT_XXL
>  #undef CONFIG_PARAVIRT_XXL
> +#endif
> +#ifdef CONFIG_PARAVIRT_SPINLOCKS
>  #undef CONFIG_PARAVIRT_SPINLOCKS
> +#endif
> 

That's not what I meant. Perhaps I should have said, you can't #undef 
unless you know that #include has already taken place. That is, if some 
header does #undef CONFIG_FOO on the assumption that #include 
<generated/autoconf.h> has already taken place, then it is fragile.

autoconf.h contains no multiple inclusion guard, and it gets included by 
multiple other headers, so it is prone to 0, 1 or N inclusions. Ordering 
with respect to #undef CONFIG_FOO is anyone's guess...

FYI, the build failure I was referring to looks like this. It's actually 
caused by solving the fragility problem I just described above...

  LD      arch/x86/boot/compressed/vmlinux
x86_64-linux-ld: error: unplaced orphan section `.altinstructions' from `arch/x86/boot/compressed/ident_map_64.o'
x86_64-linux-ld: error: unplaced orphan section `.altinstr_replacement' from `arch/x86/boot/compressed/ident_map_64.o'
x86_64-linux-ld: error: unplaced orphan section `.altinstr_aux' from `arch/x86/boot/compressed/ident_map_64.o'
x86_64-linux-ld: arch/x86/boot/compressed/ident_map_64.o: in function `ident_p4d_init':
ident_map_64.c:(.text+0x57f): undefined reference to `__pti_set_user_pgtbl'
x86_64-linux-ld: arch/x86/boot/compressed/ident_map_64.o: in function `kernel_ident_mapping_init':
ident_map_64.c:(.text+0x8ab): undefined reference to `__pti_set_user_pgtbl'
x86_64-linux-ld: arch/x86/boot/compressed/ident_map_64.o:(.altinstr_aux+0x2): undefined reference to `boot_cpu_data'
x86_64-linux-ld: arch/x86/boot/compressed/ident_map_64.o:(.altinstr_aux+0x14): undefined reference to `boot_cpu_data'
x86_64-linux-ld: arch/x86/boot/compressed/ident_map_64.o:(.altinstr_aux+0x26): undefined reference to `boot_cpu_data'
x86_64-linux-ld: arch/x86/boot/compressed/vmlinux: hidden symbol `__pti_set_user_pgtbl' isn't defined
x86_64-linux-ld: final link failed: bad value
make[3]: *** [arch/x86/boot/compressed/Makefile:119: arch/x86/boot/compressed/vmlinux] Error 1
make[2]: *** [arch/x86/boot/Makefile:96: arch/x86/boot/compressed/vmlinux] Error 2
make[1]: *** [arch/x86/Makefile:310: bzImage] Error 2
make: *** [Makefile:248: __sub-make] Error 2

If you wish to try that experiment, you'll probably need something like this:

./scripts/config -e WERROR -e LD_ORPHAN_WARN --set-str LD_ORPHAN_WARN_LEVEL error -e EFI_STUB -e CPU_SUP_AMD -e AMD_MEM_ENCRYPT

Re: linux-next: build failure after merge of the mm-nonmm-unstable tree

[Ard Biesheuvel]

On Fri, 26 Dec 2025 at 17:45, Sasha Levin <sashal@kernel.org> wrote:
>
> On Sun, Dec 21, 2025 at 01:58:17PM +1100, Finn Thain wrote:
> >
> >On Thu, 18 Dec 2025, Stephen Rothwell wrote:
> >
> >> After merging the mm-nonmm-unstable tree, today's linux-next build
> >> (x86_64 allmodconfig) failed like this:
> >>
> >> x86_64-linux-gnu-ld: error: unplaced orphan section `__bug_table' from `arch/x86/boot/compressed/sev-handle-vc.o'
> >>
> >
> >I found that I could reproduce the same build failure after applying
> >Peter's patch to v6.19-rc1. So it's not confined to linux-next. I used
> >allnoconfig with CONFIG_LD_ORPHAN_WARN_LEVEL=error and
> >CONFIG_AMD_MEM_ENCRYPT=y because allmodconfig takes forever to build.
> >
> >The patch in question is this one:
> >https://lore.kernel.org/lkml/0c18fd08ef19497768070783da28086e01d11a00.1765866665.git.fthain@linux-m68k.org/
> >
> >I may have found a solution for the problem, but I don't understand this
> >code, so I've Cc'd Ard et al. I don't know whether the __bug_table section
> >is relevant to sev-handle-vc.c. If that section is not desired, I propose
> >to make this change to Peter's patch --
>
> I think that the issue here is that we're trying to use WARN in the early boot
> context. We should probably add CONFIG_DEBUG_ATOMIC to the list of configs we
> disable for that:
>
> diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
> index 4f86c5903e03..bb36dcef7d08 100644
> --- a/arch/x86/boot/compressed/misc.h
> +++ b/arch/x86/boot/compressed/misc.h
> @@ -14,6 +14,7 @@
>   #undef CONFIG_ARCH_HAS_LAZY_MMU_MODE
>   #undef CONFIG_KASAN
>   #undef CONFIG_KASAN_GENERIC
> +#undef CONFIG_DEBUG_ATOMIC
>

In spite of the prior art, #undef'ing CONFIG_ options is the worst
possible way of dealing with this, as it could result in
inconsistencies (as Finn already found). And it is definitely not
something that belongs in generic code - the x86 decompressor is
somewhat of a lost cause at this point, I'm afraid.

In this case, I'd prefer it if we added a helper, rather than
duplicating the same check 3 times. But in this check, testing for
__DISABLE_EXPORTS is perfectly reasonable: it is already used in this
manner across architectures.

Re: linux-next: build failure after merge of the mm-nonmm-unstable tree

[Finn Thain]

On Fri, 2 Jan 2026, Ard Biesheuvel wrote:

> 
> In this case, I'd prefer it if we added a helper, rather than 
> duplicating the same check 3 times.

Yes, and the next patch in that series did add that helper. I didn't want 
to rewrite Peter's patch and drop his authorship credit, so I added the 
helper in my own patch... but being that Peter still hasn't sent a 
signed-off-by tag, I should probably fold those patches together and take 
the authorship credit/blame myself.

> But in this check, testing for __DISABLE_EXPORTS is perfectly 
> reasonable: it is already used in this manner across architectures.
> 

I think Sasha's objection was valid, in that bug table entries are said to 
be emitted, whereas symbols and interfaces are exported (and imported). 
But I agree that he may have overlooked the precendent for such use/abuse 
of that macro e.g. in arch/x86/include/asm/ibt.h.

Ard, what do you think about __DISABLE_BUG_TABLE? Shall I change it back 
to __DISABLE_EXPORTS if/when I resubmit this series? I'm ambivalent about 
it.

linux-next: build failure after merge of the mm-nonmm-unstable tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 498 bytes --]

Hi all,

After merging the mm-nonmm-unstable tree, today's linux-next build
(x86_64 allmodconfig) failed like this:

/tmp/next/build/drivers/input/misc/pf1550-onkey.c:179:8: error: extra tokens at end of #endif directive [-Werror=endif-labels]
  179 | #endif CONFIG_PM_SLEEP
      |        ^~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

Caused by commit

  f88534a6e7afc (drivers/input/misc/pf1550-onkey.c: fix build with CONFIG_PM_SLEEP=n)

I have used the tree from 20260213 instead.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: build failure after merge of the mm-nonmm-unstable tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2023 bytes --]

Hi all,

After merging the mm-unstable tree, today's linux-next build (arm64
kunit) failed like this:

[13:30:42] # hpcc_test_compare_value_boundaries: EXPECTATION FAILED at lib/tests/percpu_counter_tree_kunit.c:157
[13:30:42] Expected 1 == percpu_counter_tree_precise_compare_value(&pct, (long)under), but
[13:30:42]     percpu_counter_tree_precise_compare_value(&pct, (long)under) == 0 (0x0)
[13:30:42] # hpcc_test_compare_value_boundaries: EXPECTATION FAILED at lib/tests/percpu_counter_tree_kunit.c:160
[13:30:42] Expected -1 == percpu_counter_tree_precise_compare_value(&pct, -(long)over), but
[13:30:42]     percpu_counter_tree_precise_compare_value(&pct, -(long)over) == 0 (0x0)
[13:30:42] [FAILED] hpcc_test_compare_value_boundaries
[13:30:42] # hpcc_test_compare_counter_boundaries: EXPECTATION FAILED at lib/tests/percpu_counter_tree_kunit.c:246
[13:30:42] Expected 1 == percpu_counter_tree_precise_compare(&pct[0], &pct[1]), but
[13:30:42]     percpu_counter_tree_precise_compare(&pct[0], &pct[1]) == 0 (0x0)
[13:30:42] # hpcc_test_compare_counter_boundaries: EXPECTATION FAILED at lib/tests/percpu_counter_tree_kunit.c:251
[13:30:42] Expected -1 == percpu_counter_tree_precise_compare(&pct[0], &pct[1]), but
[13:30:42]     percpu_counter_tree_precise_compare(&pct[0], &pct[1]) == 0 (0x0)
[13:30:42] [FAILED] hpcc_test_compare_counter_boundaries
[13:30:42] [PASSED] hpcc_test_init_one
[13:30:42] [PASSED] hpcc_test_set
[13:30:42]     # module: percpu_counter_tree_kunit
[13:30:42] # percpu_counter_tree: pass:8 fail:2 skip:0 total:10

...

[13:30:47] Testing complete. Ran 9088 tests: passed: 9015, failed: 2, skipped: 71
[13:30:47] Failures: percpu_counter_tree.hpcc_test_compare_value_boundaries, percpu_counter_tree.hpcc_test_compare_counter_boundaries

Triggered by commit

  ebc1ff504f557 (lib: add kunit boundary tests for percpu_counter_tree comparisons)

though as it's a newly added test it's obviously entirely plausible that
it's flagging an existing bug.  I used the tree from next-20260316
instead.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the mm-nonmm-unstable tree

[Mathieu Desnoyers]

On 2026-03-17 10:32, Mark Brown wrote:
> Hi all,
> 
> After merging the mm-unstable tree, today's linux-next build (arm64
> kunit) failed like this:
> 
> [13:30:42] # hpcc_test_compare_value_boundaries: EXPECTATION FAILED at lib/tests/percpu_counter_tree_kunit.c:157
> [13:30:42] Expected 1 == percpu_counter_tree_precise_compare_value(&pct, (long)under), but
> [13:30:42]     percpu_counter_tree_precise_compare_value(&pct, (long)under) == 0 (0x0)
> [13:30:42] # hpcc_test_compare_value_boundaries: EXPECTATION FAILED at lib/tests/percpu_counter_tree_kunit.c:160
> [13:30:42] Expected -1 == percpu_counter_tree_precise_compare_value(&pct, -(long)over), but
> [13:30:42]     percpu_counter_tree_precise_compare_value(&pct, -(long)over) == 0 (0x0)
> [13:30:42] [FAILED] hpcc_test_compare_value_boundaries
> [13:30:42] # hpcc_test_compare_counter_boundaries: EXPECTATION FAILED at lib/tests/percpu_counter_tree_kunit.c:246
> [13:30:42] Expected 1 == percpu_counter_tree_precise_compare(&pct[0], &pct[1]), but
> [13:30:42]     percpu_counter_tree_precise_compare(&pct[0], &pct[1]) == 0 (0x0)
> [13:30:42] # hpcc_test_compare_counter_boundaries: EXPECTATION FAILED at lib/tests/percpu_counter_tree_kunit.c:251
> [13:30:42] Expected -1 == percpu_counter_tree_precise_compare(&pct[0], &pct[1]), but
> [13:30:42]     percpu_counter_tree_precise_compare(&pct[0], &pct[1]) == 0 (0x0)
> [13:30:42] [FAILED] hpcc_test_compare_counter_boundaries
> [13:30:42] [PASSED] hpcc_test_init_one
> [13:30:42] [PASSED] hpcc_test_set
> [13:30:42]     # module: percpu_counter_tree_kunit
> [13:30:42] # percpu_counter_tree: pass:8 fail:2 skip:0 total:10
> 
> ...
> 
> [13:30:47] Testing complete. Ran 9088 tests: passed: 9015, failed: 2, skipped: 71
> [13:30:47] Failures: percpu_counter_tree.hpcc_test_compare_value_boundaries, percpu_counter_tree.hpcc_test_compare_counter_boundaries
> 
> Triggered by commit
> 
>    ebc1ff504f557 (lib: add kunit boundary tests for percpu_counter_tree comparisons)
> 
> though as it's a newly added test it's obviously entirely plausible that
> it's flagging an existing bug.  I used the tree from next-20260316
> instead.

I've been able to reproduce with 1 cpu:

branch: mm-unstable
commit dffde584d805 ("zram: propagate read_from_bdev_async() errors")

cat .kunit/.kunitconfig
CONFIG_KUNIT=y
CONFIG_SMP=y
CONFIG_PREEMPT=y
CONFIG_NR_CPUS=32
CONFIG_HOTPLUG_CPU=y
CONFIG_PERCPU_COUNTER_TREE_TEST=y

/tools/testing/kunit/kunit.py run --arch=x86_64 --qemu_args="-smp 1"

[10:48:04] Configuring KUnit Kernel ...
[10:48:04] Building KUnit Kernel ...
Populating config with:
$ make ARCH=x86_64 O=.kunit olddefconfig
Building with:
$ make all compile_commands.json scripts_gdb ARCH=x86_64 O=.kunit --jobs=384
[10:48:07] Starting KUnit Kernel (1/1)...
[10:48:07] ============================================================
Running tests with:
$ qemu-system-x86_64 -nodefaults -m 1024 -kernel .kunit/arch/x86/boot/bzImage -append 'kunit.enable=1 console=ttyS0 kunit_shutdown=reboot' -no-reboot -nographic -accel kvm -accel hvf -accel tcg -serial stdio -bios qboot.rom -smp 1
[10:48:08] ============ percpu_counter_tree (10 subtests) =============
[10:48:08] [PASSED] hpcc_print_info
[10:48:15] [PASSED] hpcc_test_single_thread_first
[10:48:19] [PASSED] hpcc_test_single_thread_first_random
[10:48:19] [PASSED] hpcc_test_single_thread_random
[10:48:34] [PASSED] hpcc_test_multi_thread_batch_increment
[10:48:34] [PASSED] hpcc_test_multi_thread_random_walk
[10:48:34] # hpcc_test_compare_value_boundaries: EXPECTATION FAILED at lib/tests/percpu_counter_tree_kunit.c:157
[10:48:34] Expected 1 == percpu_counter_tree_precise_compare_value(&pct, (long)under), but
[10:48:34]     percpu_counter_tree_precise_compare_value(&pct, (long)under) == 0 (0x0)
[10:48:34] # hpcc_test_compare_value_boundaries: EXPECTATION FAILED at lib/tests/percpu_counter_tree_kunit.c:160
[10:48:34] Expected -1 == percpu_counter_tree_precise_compare_value(&pct, -(long)over), but
[10:48:34]     percpu_counter_tree_precise_compare_value(&pct, -(long)over) == 0 (0x0)
[10:48:34] [FAILED] hpcc_test_compare_value_boundaries
[10:48:34] # hpcc_test_compare_counter_boundaries: EXPECTATION FAILED at lib/tests/percpu_counter_tree_kunit.c:246
[10:48:34] Expected 1 == percpu_counter_tree_precise_compare(&pct[0], &pct[1]), but
[10:48:34]     percpu_counter_tree_precise_compare(&pct[0], &pct[1]) == 0 (0x0)
[10:48:34] # hpcc_test_compare_counter_boundaries: EXPECTATION FAILED at lib/tests/percpu_counter_tree_kunit.c:251
[10:48:34] Expected -1 == percpu_counter_tree_precise_compare(&pct[0], &pct[1]), but
[10:48:34]     percpu_counter_tree_precise_compare(&pct[0], &pct[1]) == 0 (0x0)
[10:48:34] [FAILED] hpcc_test_compare_counter_boundaries
[10:48:34] [PASSED] hpcc_test_init_one
[10:48:34] [PASSED] hpcc_test_set
[10:48:34]     # module: percpu_counter_tree_kunit
[10:48:34] # percpu_counter_tree: pass:8 fail:2 skip:0 total:10
[10:48:34] # Totals: pass:8 fail:2 skip:0 total:10
[10:48:34] =============== [FAILED] percpu_counter_tree ===============
[10:48:34] ============================================================
[10:48:34] Testing complete. Ran 10 tests: passed: 8, failed: 2
[10:48:34] Elapsed time: 30.726s total, 0.001s configuring, 3.074s building, 27.600s running

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com

Re: linux-next: build failure after merge of the mm-nonmm-unstable tree

[David CARLIER]

Hi all I ve send a patch to all involved parties. Cheers.

On Tue, 17 Mar 2026 at 15:06, Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> wrote:
>
> On 2026-03-17 10:32, Mark Brown wrote:
> > Hi all,
> >
> > After merging the mm-unstable tree, today's linux-next build (arm64
> > kunit) failed like this:
> >
> > [13:30:42] # hpcc_test_compare_value_boundaries: EXPECTATION FAILED at lib/tests/percpu_counter_tree_kunit.c:157
> > [13:30:42] Expected 1 == percpu_counter_tree_precise_compare_value(&pct, (long)under), but
> > [13:30:42]     percpu_counter_tree_precise_compare_value(&pct, (long)under) == 0 (0x0)
> > [13:30:42] # hpcc_test_compare_value_boundaries: EXPECTATION FAILED at lib/tests/percpu_counter_tree_kunit.c:160
> > [13:30:42] Expected -1 == percpu_counter_tree_precise_compare_value(&pct, -(long)over), but
> > [13:30:42]     percpu_counter_tree_precise_compare_value(&pct, -(long)over) == 0 (0x0)
> > [13:30:42] [FAILED] hpcc_test_compare_value_boundaries
> > [13:30:42] # hpcc_test_compare_counter_boundaries: EXPECTATION FAILED at lib/tests/percpu_counter_tree_kunit.c:246
> > [13:30:42] Expected 1 == percpu_counter_tree_precise_compare(&pct[0], &pct[1]), but
> > [13:30:42]     percpu_counter_tree_precise_compare(&pct[0], &pct[1]) == 0 (0x0)
> > [13:30:42] # hpcc_test_compare_counter_boundaries: EXPECTATION FAILED at lib/tests/percpu_counter_tree_kunit.c:251
> > [13:30:42] Expected -1 == percpu_counter_tree_precise_compare(&pct[0], &pct[1]), but
> > [13:30:42]     percpu_counter_tree_precise_compare(&pct[0], &pct[1]) == 0 (0x0)
> > [13:30:42] [FAILED] hpcc_test_compare_counter_boundaries
> > [13:30:42] [PASSED] hpcc_test_init_one
> > [13:30:42] [PASSED] hpcc_test_set
> > [13:30:42]     # module: percpu_counter_tree_kunit
> > [13:30:42] # percpu_counter_tree: pass:8 fail:2 skip:0 total:10
> >
> > ...
> >
> > [13:30:47] Testing complete. Ran 9088 tests: passed: 9015, failed: 2, skipped: 71
> > [13:30:47] Failures: percpu_counter_tree.hpcc_test_compare_value_boundaries, percpu_counter_tree.hpcc_test_compare_counter_boundaries
> >
> > Triggered by commit
> >
> >    ebc1ff504f557 (lib: add kunit boundary tests for percpu_counter_tree comparisons)
> >
> > though as it's a newly added test it's obviously entirely plausible that
> > it's flagging an existing bug.  I used the tree from next-20260316
> > instead.
>
> I've been able to reproduce with 1 cpu:
>
> branch: mm-unstable
> commit dffde584d805 ("zram: propagate read_from_bdev_async() errors")
>
> cat .kunit/.kunitconfig
> CONFIG_KUNIT=y
> CONFIG_SMP=y
> CONFIG_PREEMPT=y
> CONFIG_NR_CPUS=32
> CONFIG_HOTPLUG_CPU=y
> CONFIG_PERCPU_COUNTER_TREE_TEST=y
>
> /tools/testing/kunit/kunit.py run --arch=x86_64 --qemu_args="-smp 1"
>
> [10:48:04] Configuring KUnit Kernel ...
> [10:48:04] Building KUnit Kernel ...
> Populating config with:
> $ make ARCH=x86_64 O=.kunit olddefconfig
> Building with:
> $ make all compile_commands.json scripts_gdb ARCH=x86_64 O=.kunit --jobs=384
> [10:48:07] Starting KUnit Kernel (1/1)...
> [10:48:07] ============================================================
> Running tests with:
> $ qemu-system-x86_64 -nodefaults -m 1024 -kernel .kunit/arch/x86/boot/bzImage -append 'kunit.enable=1 console=ttyS0 kunit_shutdown=reboot' -no-reboot -nographic -accel kvm -accel hvf -accel tcg -serial stdio -bios qboot.rom -smp 1
> [10:48:08] ============ percpu_counter_tree (10 subtests) =============
> [10:48:08] [PASSED] hpcc_print_info
> [10:48:15] [PASSED] hpcc_test_single_thread_first
> [10:48:19] [PASSED] hpcc_test_single_thread_first_random
> [10:48:19] [PASSED] hpcc_test_single_thread_random
> [10:48:34] [PASSED] hpcc_test_multi_thread_batch_increment
> [10:48:34] [PASSED] hpcc_test_multi_thread_random_walk
> [10:48:34] # hpcc_test_compare_value_boundaries: EXPECTATION FAILED at lib/tests/percpu_counter_tree_kunit.c:157
> [10:48:34] Expected 1 == percpu_counter_tree_precise_compare_value(&pct, (long)under), but
> [10:48:34]     percpu_counter_tree_precise_compare_value(&pct, (long)under) == 0 (0x0)
> [10:48:34] # hpcc_test_compare_value_boundaries: EXPECTATION FAILED at lib/tests/percpu_counter_tree_kunit.c:160
> [10:48:34] Expected -1 == percpu_counter_tree_precise_compare_value(&pct, -(long)over), but
> [10:48:34]     percpu_counter_tree_precise_compare_value(&pct, -(long)over) == 0 (0x0)
> [10:48:34] [FAILED] hpcc_test_compare_value_boundaries
> [10:48:34] # hpcc_test_compare_counter_boundaries: EXPECTATION FAILED at lib/tests/percpu_counter_tree_kunit.c:246
> [10:48:34] Expected 1 == percpu_counter_tree_precise_compare(&pct[0], &pct[1]), but
> [10:48:34]     percpu_counter_tree_precise_compare(&pct[0], &pct[1]) == 0 (0x0)
> [10:48:34] # hpcc_test_compare_counter_boundaries: EXPECTATION FAILED at lib/tests/percpu_counter_tree_kunit.c:251
> [10:48:34] Expected -1 == percpu_counter_tree_precise_compare(&pct[0], &pct[1]), but
> [10:48:34]     percpu_counter_tree_precise_compare(&pct[0], &pct[1]) == 0 (0x0)
> [10:48:34] [FAILED] hpcc_test_compare_counter_boundaries
> [10:48:34] [PASSED] hpcc_test_init_one
> [10:48:34] [PASSED] hpcc_test_set
> [10:48:34]     # module: percpu_counter_tree_kunit
> [10:48:34] # percpu_counter_tree: pass:8 fail:2 skip:0 total:10
> [10:48:34] # Totals: pass:8 fail:2 skip:0 total:10
> [10:48:34] =============== [FAILED] percpu_counter_tree ===============
> [10:48:34] ============================================================
> [10:48:34] Testing complete. Ran 10 tests: passed: 8, failed: 2
> [10:48:34] Elapsed time: 30.726s total, 0.001s configuring, 3.074s building, 27.600s running
>
> Thanks,
>
> Mathieu
>
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> https://www.efficios.com