The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Nicolas Schier <nsc@kernel.org>
To: Petr Mladek <pmladek@suse.com>
Cc: "Thomas Weißschuh" <thomas.weissschuh@linutronix.de>,
	sashiko-reviews@lists.linux.dev,
	"Nathan Chancellor" <nathan@kernel.org>,
	live-patching@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-kselftest@vger.kernel.org,
	"Miroslav Benes" <mbenes@suse.cz>,
	shuah@kernel.org, "Zelin Deng" <zelin.deng@linux.alibaba.com>,
	linux-kbuild@vger.kernel.org
Subject: Re: [PATCH] kbuild: unset sub_make_done before calling kselftest build system
Date: Fri, 3 Jul 2026 21:24:29 +0200	[thread overview]
Message-ID: <akgMbd9fFOZYXUoC@levanger> (raw)
In-Reply-To: <akeJto1TC2CSs4Yw@pathway.suse.cz>

On Fri, Jul 03, 2026 at 12:06:46PM +0200, Petr Mladek wrote:
> On Fri 2026-07-03 11:32:30, Thomas Weißschuh wrote:
> > On Fri, Jul 03, 2026 at 10:26:07AM +0200, Petr Mladek wrote:
> > > On Fri 2026-07-03 06:14:48, sashiko-bot@kernel.org wrote:
> > > > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > > > - [Medium] Incomplete fix and inconsistent state: The patch correctly unsets `sub_make_done` for the `kselftest` targets to allow Kbuild command-line reevaluation when building external kernel modules. However, it fails to apply the same logic to the `tools/` and `tools/%` targets, introducing a discrepancy between build entry points.
> > > > --
> > > > 
> > > > commit 06c418388d65deb3d8494a6e8e7071c0e709186b
> > > > Author: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> > > > 
> > > > kbuild: unset sub_make_done before calling kselftest build system
> > > > 
> > > > This commit unsets sub_make_done before invoking the kselftest build system to
> > > > ensure Kbuild reevaluates command-line flags when building test modules. It
> > > > mirrors a previous fix done for scripts/install.sh.
> > > > 
> > > > > diff --git a/Makefile b/Makefile
> > > > > index b9c5792c79e01..f717a4dc96d6a 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
> > > > 
> > > > [Severity: Medium]
> > > > Will make tools/selftests still fail after this change?
> > > > 
> > > > The tools/ and tools/% targets in Makefile delegate to the tools build
> > > > system, which can also trigger external kernel module builds (like bpf_testmod).
> > > > 
> > > > Because sub_make_done is not unset for these targets, invoking commands like
> > > > make tools/selftests or make tools/all will skip Kbuild's M= argument parsing.
> > > > 
> > > > Should sub_make_done also be unset in the tools/ and tools/% targets to maintain
> > > > consistency across the build entry points?
> > > 
> > > This might make sense. I see that the tools: and tools/%: targets are
> > > defined right above the kselftest*: ones. And they are even advertised
> > > in "make help" or "make tools/help".
> > 
> > I am not sure how the tools/ targets can reach back into kbuild.
> > The example with bpf_testmod above is bogus, as tools/* is only for
> > top-level tools directories. Subdirectories in tools/testing/selftests/
> > don't seem to be reachable.
> 
> I see.
> 
> > > Well it probably should be done in a separate patch. It would be better
> > > for bisecting potential regressions. Thomas, Zelin, what do you think, please?
> > 
> > If we do it for consistency it should be its own patch, agreed.
> 
> I would keep it as is until anyone reports a real problem.

Ack.

Thomas, thanks for fix!

Reviewed-by: Nicolas Schier <nsc@kernel.org>


-- 
Nicolas

  reply	other threads:[~2026-07-03 19:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-03  6:04 [PATCH] kbuild: unset sub_make_done before calling kselftest build system Thomas Weißschuh
2026-07-03  6:14 ` sashiko-bot
2026-07-03  8:26   ` Petr Mladek
2026-07-03  9:32     ` Thomas Weißschuh
2026-07-03 10:06       ` Petr Mladek
2026-07-03 19:24         ` Nicolas Schier [this message]
2026-07-03  8:25 ` Petr Mladek
2026-07-03 19:25   ` Nicolas Schier
2026-07-04  1:59   ` Zelin Deng
2026-07-03  8:39 ` Miroslav Benes

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=akgMbd9fFOZYXUoC@levanger \
    --to=nsc@kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=nathan@kernel.org \
    --cc=pmladek@suse.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --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