From: Shuah Khan <skhan@linuxfoundation.org>
To: Nicolas Schier <nicolas.schier@linux.dev>
Cc: masahiroy@kernel.org, nathan@kernel.org,
brendan.higgins@linux.dev, davidgow@google.com, rmoar@google.com,
linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
kunit-dev@googlegroups.com, linux-kselftest@vger.kernel.org,
Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH] kbuild: use ARCH from compile.h in unclean source tree msg
Date: Tue, 6 May 2025 18:20:53 -0600 [thread overview]
Message-ID: <37234cf8-ac79-45b8-9bcf-dcf4792b9877@linuxfoundation.org> (raw)
In-Reply-To: <0d27886e-5a3c-4073-a044-f6684de8333d@linuxfoundation.org>
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@linuxfoundation.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
next prev parent reply other threads:[~2025-05-07 0:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-02 17:24 [PATCH] kbuild: use ARCH from compile.h in unclean source tree msg Shuah Khan
2025-05-05 6:02 ` David Gow
2025-05-06 11:12 ` Nicolas Schier
2025-05-06 22:07 ` Shuah Khan
2025-05-07 0:20 ` Shuah Khan [this message]
2025-05-07 7:23 ` Masahiro Yamada
2025-05-07 22:21 ` Shuah Khan
2025-05-07 22:48 ` Shuah Khan
2025-05-07 12:09 ` Masahiro Yamada
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=37234cf8-ac79-45b8-9bcf-dcf4792b9877@linuxfoundation.org \
--to=skhan@linuxfoundation.org \
--cc=brendan.higgins@linux.dev \
--cc=davidgow@google.com \
--cc=kunit-dev@googlegroups.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=nathan@kernel.org \
--cc=nicolas.schier@linux.dev \
--cc=rmoar@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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