linux-kernel - Re: [PATCH] kbuild: use ARCH from compile.h in unclean source tree msg

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <37234cf8-ac79-45b8-9bcf-dcf4792b9877@linuxfoundation.org>
Date: Tue, 6 May 2025 18:20:53 -0600
From: Shuah Khan <skhan@...uxfoundation.org>
To: Nicolas Schier <nicolas.schier@...ux.dev>
Cc: masahiroy@...nel.org, nathan@...nel.org, brendan.higgins@...ux.dev,
 davidgow@...gle.com, rmoar@...gle.com, linux-kbuild@...r.kernel.org,
 linux-kernel@...r.kernel.org, kunit-dev@...glegroups.com,
 linux-kselftest@...r.kernel.org, Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH] kbuild: use ARCH from compile.h in unclean source tree
 msg

On 5/6/25 16:07, Shuah Khan wrote:
> On 5/6/25 05:12, Nicolas Schier wrote:
>> On Fri, 02 May 2025, Shuah Khan wrote:
>>
>>> When make finds the source tree unclean, it prints a message to run
>>> "make ARCH=x86_64 mrproper" message using the ARCH from the command
>>> line. The ARCH specified in the command line could be different from
>>> the ARCH of the existing build in the source tree.
>>>
>>> This could cause problems in regular kernel build and kunit workflows.
>>>
>>> Regular workflow:
>>>
>>> - Build x86_64 kernel
>>>     $ make ARCH=x86_64
>>> - Try building another arch kernel out of tree with O=
>>>     $ make ARCH=um O=/linux/build
>>> - kbuild detects source tree is unclean
>>>
>>>    ***
>>>    *** The source tree is not clean, please run 'make ARCH=um mrproper'
>>>    *** in /linux/linux_srcdir
>>>    ***
>>>
>>> - Clean source tree as suggested by kbuild
>>>     $ make ARCH=um mrproper
>>> - Source clean appears to be clean, but it leaves behind generated header
>>>    files under arch/x86
>>>       arch/x86/realmode/rm/pasyms.h
>>>
>>> A subsequent x86_64e build fails with
>>>    "undefined symbol sev_es_trampoline_start referenced ..."
>>>
>>> kunit workflow runs into this issue:
>>>
>>> - Build x86_64 kernel
>>> - Run kunit tests:  it tries to build for user specified ARCH or uml
>>>    as default:
>>>     $ ./tools/testing/kunit/kunit.py run
>>>
>>> - kbuild detects unclean source tree
>>>
>>>    ***
>>>    *** The source tree is not clean, please run 'make ARCH=um mrproper'
>>>    *** in /linux/linux_6.15
>>>    ***
>>>
>>> - Clean source tree as suggested by kbuild
>>>     $ make ARCH=um mrproper
>>> - Source clean appears to be clean, but it leaves behind generated header
>>>    files under arch/x86
>>>
>>> The problem shows when user tries to run tests on ARCH=x86_64:
>>>
>>>     $ ./tools/testing/kunit/kunit.py run ARCH=x86_64
>>>
>>>     "undefined symbol sev_es_trampoline_start referenced ..."
>>>
>>> Build trips on arch/x86/realmode/rm/pasyms.h left behind by a prior
>>> x86_64 build.
>>>
>>> Problems related to partially cleaned source tree are hard to debug.
>>> Change Makefile to unclean source logic to use ARCH from compile.h
>>> UTS_MACHINE string. With this change kbuild prints:
>>>
>>>     $ ./tools/testing/kunit/kunit.py run
>>>
>>>    ***
>>>    *** The source tree is not clean, please run 'make ARCH=x86_64 mrproper'
>>>    *** in /linux/linux_6.15
>>>    ***
>>>
>>> Signed-off-by: Shuah Khan <skhan@...uxfoundation.org>
>>> ---
>>>   Makefile | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/Makefile b/Makefile
>>> index 5aa9ee52a765..7ee29136b4da 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -674,7 +674,7 @@ ifeq ($(KBUILD_EXTMOD),)
>>>            -d $(srctree)/include/config -o \
>>>            -d $(srctree)/arch/$(SRCARCH)/include/generated ]; then \
> 
> Would it make sense to check for include/generated as a catch all?

Adding check is good, but it won't cover the compile.h missing. I don't
know if compile.h could go missing if include/generated exists. In any
case, it is good to check for compile exists or not and print appropriate
message for these cases.

I have the change working. Will send it out. Thanks for the tip on
the (rare) cases.

thanks,
-- Shuah