From: Finn Thain <fthain@linux-m68k•org>
To: Randy Dunlap <rdunlap@infradead•org>
Cc: Sasha Levin <sashal@kernel•org>,
Peter Zijlstra <peterz@infradead•org>,
Ard Biesheuvel <ardb@kernel•org>,
Andrew Morton <akpm@linux-foundation•org>,
Will Deacon <will@kernel•org>, Arnd Bergmann <arnd@arndb•de>,
Stephen Rothwell <sfr@canb•auug.org.au>,
x86@kernel•org,
Linux Kernel Mailing List <linux-kernel@vger•kernel.org>,
Linux Next Mailing List <linux-next@vger•kernel.org>
Subject: Re: linux-next: build failure after merge of the mm-nonmm-unstable tree
Date: Fri, 2 Jan 2026 10:15:39 +1100 (AEDT) [thread overview]
Message-ID: <84ebf3ef-1385-1b11-772b-7bccac4d25ae@linux-m68k.org> (raw)
In-Reply-To: <77d3d65a-9ef0-451e-b24f-1b3f38cf822b@infradead.org>
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
next prev parent reply other threads:[~2026-01-01 23:15 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-18 4:30 linux-next: build failure after merge of the mm-nonmm-unstable tree Stephen Rothwell
2025-12-21 2:58 ` Finn Thain
2025-12-26 16:45 ` Sasha Levin
2025-12-29 8:56 ` Finn Thain
2026-01-01 9:21 ` Finn Thain
2026-01-01 17:01 ` Randy Dunlap
2026-01-01 23:15 ` Finn Thain [this message]
2026-01-02 7:29 ` Ard Biesheuvel
2026-01-02 22:09 ` Finn Thain
-- strict thread matches above, loose matches on Subject: below --
2026-04-29 9:10 Thierry Reding
2026-03-17 14:32 Mark Brown
2026-03-17 15:06 ` Mathieu Desnoyers
2026-03-17 15:07 ` David CARLIER
2026-02-16 13:58 Mark Brown
2025-11-16 23:23 Stephen Rothwell
2025-11-19 23:14 ` Stephen Rothwell
2025-11-19 23:48 ` Andrew Morton
2025-11-20 8:55 ` Miguel Ojeda
2025-11-20 10:01 ` Alice Ryhl
2025-11-16 22:36 Stephen Rothwell
2025-10-17 13:25 Mark Brown
2025-10-17 21:34 ` Andrew Morton
2025-09-01 1:17 Stephen Rothwell
2025-07-11 0:58 Stephen Rothwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=84ebf3ef-1385-1b11-772b-7bccac4d25ae@linux-m68k.org \
--to=fthain@linux-m68k$(echo .)org \
--cc=akpm@linux-foundation$(echo .)org \
--cc=ardb@kernel$(echo .)org \
--cc=arnd@arndb$(echo .)de \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=peterz@infradead$(echo .)org \
--cc=rdunlap@infradead$(echo .)org \
--cc=sashal@kernel$(echo .)org \
--cc=sfr@canb$(echo .)auug.org.au \
--cc=will@kernel$(echo .)org \
--cc=x86@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox