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

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