Re: [PATCH] selftests: livepatch: unset sub_make_done in case top level Makefile be overwritten

Thomas Weißschuh <[email protected]> Wed, 1 Jul 2026 17:19:46 +0200
Newsgroups org.kernel.vger.live-patching,org.kernel.vger.linux-kbuild,org.kernel.vger.linux-kselftest
Message-ID <20260701171713-7dd2f65f-abe2-4ae6-bcd4-e0bcdada6bed@linutronix.de>
On Wed, Jul 01, 2026 at 05:14:24PM +0200, Petr Mladek wrote:
> On Tue 2026-06-30 18:12:46, Thomas Weißschuh wrote:
> > Hi Zelin,
> > 
> > On Tue, Jun 30, 2026 at 04:32:16PM +0200, Petr Mladek wrote:
> > > Added some people involved in "filechk_makefile" feature into Cc.
> > > 
> > > For the new people, see the whole thread at
> > > https://lore.kernel.org/all/[email protected]/
> > 
> > Thanks for the report and forwarding it.
> > 
> > > 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:
> > > > 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.
> > 
> > Can you try this:
> > 
> > diff --git a/Makefile b/Makefile
> > index b9c5792c79e0..f717a4dc96d6 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1591,10 +1591,10 @@ tools/%: FORCE
> >  
> >  PHONY += kselftest
> >  kselftest: headers
> > -	$(Q)$(MAKE) -C $(srctree)/tools/testing/selftests run_tests
> > +	$(Q)unset sub_make_done; $(MAKE) -C $(srctree)/tools/testing/selftests run_tests
> >  
> >  kselftest-%: headers FORCE
> > -	$(Q)$(MAKE) -C $(srctree)/tools/testing/selftests $*
> > +	$(Q)unset sub_make_done; $(MAKE) -C $(srctree)/tools/testing/selftests $*
> >  
> >  PHONY += kselftest-merge
> >  kselftest-merge:
> 
> Heh, this is exactly the same change which Zelin Deng proposed as
> well, see
> https://lore.kernel.org/all/[email protected]/

The difference is that my proposal is in the toplevel Makefile while
Zelin's is in the selftest one. The toplevel one should fix all selftests at
the same time.

> > The same is done for cmd_install.
> 
> I guess that this is related to the commit 14ccc638b02f9ec ("kbuild:
> cancel sub_make_done for the install target to fix DKMS"). Which
> is related to the commit bcf637f54f6d2515d ("kbuild: parse C= and M=
> before changing the working directory").
> 
> Honestly, it all looks like a wild magic to me. I would need much
> better understanding of the Makefile maze to get on top of it.

I was not able to reproduce the issue yet. My proposal is just a guess.
We'll need feedback from Zelin.

> But it seems that it is a reasonable fix after all. It solves the
> original problem. It does not break my workflow. So, I tend to add:
> 
> Acked-by: Petr Mladek <[email protected]>


Thomas