Live Patching
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Zelin Deng <zelin.deng@linux.alibaba.com>
Cc: "Miroslav Benes" <mbenes@suse.cz>,
	shuah@kernel.org, linux-kselftest@vger.kernel.org,
	live-patching@vger.kernel.org, mpdesouza@suse.com,
	"Thomas Weißschuh" <thomas.weissschuh@linutronix.de>,
	"Nathan Chancellor" <nathan@kernel.org>,
	"Nicolas Schier" <nsc@kernel.org>,
	linux-kbuild@vger.kernel.org
Subject: Re: [PATCH] selftests: livepatch: unset sub_make_done in case top level Makefile be overwritten
Date: Tue, 30 Jun 2026 16:32:16 +0200	[thread overview]
Message-ID: <akPTcJjrIAI1ZNyH@pathway.suse.cz> (raw)
In-Reply-To: <ccfed9b6-9a73-4299-b305-da7b593a52fd@linux.alibaba.com>

Added some people involved in "filechk_makefile" feature into Cc.

For the new people, see the whole thread at
https://lore.kernel.org/all/20260525083721.27857-1-zelin.deng@linux.alibaba.com/

On Sun 2026-06-21 22:36:24, Zelin Deng wrote:
> 
> 在 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.

It seems that "filechk_makefile" has reached mainline in v7.1-rc1,
see the commit c9bb03ac2c66bc5aa81b ("kbuild: reduce output spam when
building out of tree").

The commit message says:

<paste>
    The Makefile is now created even if the build is aborted due to an
    unclean working tree. That should not make a difference in practice.
 </paste>

It seems that is actually makes a difference in the livepatch selftest
case.

Sigh, the Makefile rules are a maze to me. It is possible that
we do something wrong in
tools/testing/selftests/livepatch/test_modules/Makefile. Namely
with:

ifneq ("$(wildcard $(KDIR))", "")
	$(Q)$(MAKE) -C $(KDIR) modules KBUILD_EXTMOD=$(TESTMODS_DIR)
endif

But I see "$(MAKE) -C ..." called in many other makefiles.

Best Regards,
Petr

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

  reply	other threads:[~2026-06-30 14:32 UTC|newest]

Thread overview: 9+ 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
2026-06-30 14:32     ` Petr Mladek [this message]
2026-06-30 16:12       ` Thomas Weißschuh
2026-07-01 15:14         ` Petr Mladek
2026-07-01 15:19           ` Thomas Weißschuh
2026-07-02  2:40             ` Zelin Deng
2026-07-02  7:11               ` Thomas Weißschuh
2026-07-02  8:09                 ` Zelin Deng

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=akPTcJjrIAI1ZNyH@pathway.suse.cz \
    --to=pmladek@suse.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=mpdesouza@suse.com \
    --cc=nathan@kernel.org \
    --cc=nsc@kernel.org \
    --cc=shuah@kernel.org \
    --cc=thomas.weissschuh@linutronix.de \
    --cc=zelin.deng@linux.alibaba.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