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@xxxxxxxxxxxxxx/
> > >
> > >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.