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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <df9fbd22-a648-ada4-fee0-68fe4325ff82@linux-m68k.org>
Date: Mon, 29 Dec 2025 19:56:44 +1100 (AEDT)
From: Finn Thain <fthain@...ux-m68k.org>
To: Sasha Levin <sashal@...nel.org>
cc: Peter Zijlstra <peterz@...radead.org>, Ard Biesheuvel <ardb@...nel.org>, 
    Andrew Morton <akpm@...ux-foundation.org>, Will Deacon <will@...nel.org>, 
    Arnd Bergmann <arnd@...db.de>, Stephen Rothwell <sfr@...b.auug.org.au>, 
    x86@...nel.org, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, 
    Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: build failure after merge of the mm-nonmm-unstable
 tree

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.