From: Petr Mladek <pmladek@suse.com>
To: "Thomas Weißschuh" <thomas.weissschuh@linutronix.de>
Cc: sashiko-reviews@lists.linux.dev,
Nathan Chancellor <nathan@kernel.org>,
Nicolas Schier <nsc@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 12:06:46 +0200 [thread overview]
Message-ID: <akeJto1TC2CSs4Yw@pathway.suse.cz> (raw)
In-Reply-To: <20260703113019-678f1eb6-a061-435e-91a4-c0d76794b2cf@linutronix.de>
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.
Thanks a lot for explanation.
Best Regards,
Petr
next prev parent reply other threads:[~2026-07-03 10:06 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 [this message]
2026-07-03 19:24 ` Nicolas Schier
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=akeJto1TC2CSs4Yw@pathway.suse.cz \
--to=pmladek@suse.com \
--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=nsc@kernel.org \
--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