From: Zelin Deng <zelin.deng@linux.alibaba.com>
To: Miroslav Benes <mbenes@suse.cz>
Cc: shuah@kernel.org, linux-kselftest@vger.kernel.org,
live-patching@vger.kernel.org, mpdesouza@suse.com
Subject: Re: [PATCH] selftests: livepatch: unset sub_make_done in case top level Makefile be overwritten
Date: Sun, 21 Jun 2026 22:36:24 +0800 [thread overview]
Message-ID: <ccfed9b6-9a73-4299-b305-da7b593a52fd@linux.alibaba.com> (raw)
In-Reply-To: <alpine.LSU.2.21.2606191638540.26638@pobox.suse.cz>
在 2026/6/19 22:42, Miroslav Benes 写道:
> On Mon, 25 May 2026, Zelin Deng wrote:
>
>> After I did: make kselftest-all in top level of kernel source tree, top
>> level Makefile was overwritten by auto generated contents by
>> filechk_makefile:
>> [root@emr: /home/shiyu.dzl/linux-next]$ cat Makefile
>> export KBUILD_OUTPUT = .
>> export KBUILD_EXTMOD = /home/shiyu.dzl/linux-next
>> export KBUILD_EXTMOD_OUTPUT = /home/shiyu.dzl/linux-next
>> include /home/shiyu.dzl/linux-next/Makefile
>>
>> Top-level Makefile export sub_make_done=1, leaks into unrelated re-invocations
>> of the top-level Makefile when recursive descent through selftests -
>> building test_module of livepatch. That causes KBUILD_EXTMOD setup to be
>> skipped, which leads to a relative/absolute path mismatch in srcroot vs
>> CURDIR, falsely setting building_out_of_srctree, and ultimately overwriting
>> the source tree's Makefile with a generated stub.
>>
>> Clear sub_make_done before re-invoking the kernel Makefile.
>>
>> Fixes: c4bbe83d27c2 ("livepatch: Move tests from lib/livepatch to selftests/livepatch")
>> Signed-off-by: Zelin Deng <zelin.deng@linux.alibaba.com>
> Adding Marcos and KLP ML.
>
> I cannot reproduce and I do not understand it much from the changelog (I
> am by far not a Kbuild expert). Could you share the exact steps to
> reproduce please? If I just run 'make kselftest-all' in the top level, it
> passes and livepatch test_modules are not even touched.
>
> Miroslav
Thank you for replying.
Per my understanding, to build livepatch test_modules KDIR must be
either set explicitly when doing 'make kselftest-all
KDIR=<path-to-kernel-build-dir>' or have the kernel devel package
installed. Otherwise the compilation could be skipped. (see
tools/testing/selftests/livepatch/test_modules/Makefile)
KDIR ?= /lib/modules/$(shell uname -r)/build
...
# Ensure that KDIR exists, otherwise skip the compilation
modules:
ifneq ("$(wildcard $(KDIR))", "")
$(Q)$(MAKE) -C $(KDIR) modules KBUILD_EXTMOD=$(TESTMODS_DIR)
endif
...
Here're how I reproduce the issue:
1. pull linux-next, reset to HEAD, for example
3ce97bd3c4f18608335e709c24d6a40e7036cab8 (tag next-20260619)
2. at linux-next tree: make all -j$(nproc) && make modules_install
headers_install -j$(nproc) && make install && reboot
3. at linux-next tree: make kselftest-all
4. top level Makefile in linux-next has been overwritten by
export KBUILD_OUTPUT = .
export KBUILD_EXTMOD = /home/shiyu.dzl/linux-next
export KBUILD_EXTMOD_OUTPUT = /home/shiyu.dzl/linux-next
include /home/shiyu.dzl/linux-next/Makefile
it is a stub generated by filechk_makefile.
I'm not quite sure that it could be related to my toolchain (like make
version ?), I briefed analysis the root cause on my environment (KDIR
'/lib/modules/7.1.0-next-20260619/build' which actually a symbol link to
my kernel source -> '/home/shiyu.dzl/linux-next'):
1. sub_make_done leaks via environment. The top-level Makefile sets
export sub_make_done := 1 after its first-pass initialization.
Because it is exported, every child make process inherits it.
2. livepatch test_modules re-invokes the top-level Makefile. The call
chain is: top-level Makefile → kselftest-% pattern rule →
tools/testing/selftests/ → livepatch test_modules/Makefile → $(MAKE)
-C $(KDIR) modules KBUILD_EXTMOD=..., which re-enters the top-level
Makefile to
build an external module.
3. The inherited sub_make_done=1 skips critical initialization. The
top-level Makefile's first-pass block (ifneq ($(sub_make_done),1)) is
skipped entirely. This block is responsible for correctly parsing
command-line variables and setting up KBUILD_EXTMOD-related paths.
4. Path mismatch triggers false out-of-tree detection. With the
initialization skipped, srcroot and CURDIR end up with mismatched values
(e.g.,
absolute vs. relative). The comparison (ifeq ($(srcroot),$(CURDIR)))
fails, so building_out_of_srctree is incorrectly set to 1.
5. outputmakefile overwrites the source tree's Makefile. Because
building_out_of_srctree is set, the filechk_makefile rule fires and
replaces the
real top-level Makefile with a generated stub containing
KBUILD_OUTPUT, KBUILD_EXTMOD, and an include directive.
Why make -C tools/testing/selftests/ all is unaffected: it enters the
selftests directory directly without ever executing the top-level Makefile
first, so sub_make_done is never exported into the environment. When
livepatch test_modules later invokes $(MAKE) -C $(KDIR), the top-level
Makefile
runs its full initialization normally.
Thanks,
Zelin
prev parent reply other threads:[~2026-06-21 14:36 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260525083721.27857-1-zelin.deng@linux.alibaba.com>
2026-06-19 14:42 ` [PATCH] selftests: livepatch: unset sub_make_done in case top level Makefile be overwritten Miroslav Benes
2026-06-21 14:36 ` Zelin Deng [this message]
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=ccfed9b6-9a73-4299-b305-da7b593a52fd@linux.alibaba.com \
--to=zelin.deng@linux.alibaba.com \
--cc=linux-kselftest@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=mpdesouza@suse.com \
--cc=shuah@kernel.org \
/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