Message-ID: <20260203044726.GA3049363@ax162>
Date: Mon, 2 Feb 2026 21:47:26 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: David Laight <david.laight.linux@...il.com>
Cc: Yury Norov <ynorov@...dia.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Arnd Bergmann <arnd@...db.de>, linux-arch@...r.kernel.org,
	linux-kernel@...r.kernel.org, Yury Norov <yury.norov@...il.com>,
	Lucas De Marchi <lucas.demarchi@...el.com>,
	Jani Nikula <jani.nikula@...el.com>,
	Vincent Mailhol <mailhol.vincent@...adoo.fr>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Kees Cook <keescook@...omium.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH next 02/14] kbuild: Add W=c for additional compile time
 checks

On Mon, Feb 02, 2026 at 08:07:43PM +0000, David Laight wrote:
> On Mon, 2 Feb 2026 13:33:22 -0500
> Yury Norov <ynorov@...dia.com> wrote:
> 
> > On Wed, Jan 21, 2026 at 02:57:19PM +0000, david.laight.linux@...il.com wrote:
> > > From: David Laight <david.laight.linux@...il.com>
> > > 
> > > Some compile time checks significantly bloat the pre-processor output
> > > (particularly when the get nested).
> > > Since the checks aren't really needed on every compilation enable with
> > > W=c (adds -DKBUILD_EXTRA_WARNc) so the checks can be enabled per-build.
> > > Make W=1 imply W=c so the build-bot includes the checks.
> > > 
> > > As well as reducing the bloat from existing checks (like those in
> > > GENMASK() and FIELD_PREP()) it lets additional checks be added
> > > while there are still 'false positives' without breaking normal builds.
> > > 
> > > Signed-off-by: David Laight <david.laight.linux@...il.com>  
> > 
> > Honestly I don't understand this. AFAIU, you've outlined a list of
> > compiler warnings that slow the compilation down, and you group them
> > under 'W=c' option.
> > 
> > What is the use case for it outside of your series. I think, a typical
> > user would find more value in an option that enables some warnings but
> > doesn't sacrifices performance.
> 
> All the compile-time warnings slow down the compilation.
> Even apparently trivial ones (like the check in the generic READ_ONCE()
> that the size is 1, 2, 4 or 8 bytes) have a measurable effect.  

What kind of difference are we talking about here across a regular
build?

> The code a typical user compiles won't have anything that trips any of
> the compile-time asserts.
> They only really happen when compiling new code or adding new checks.
> 
> > Can you consider flipping the 'W=c' behavior?
> 
> Why, most of the time you don't want the checks because the code is
> known to pass them all.
> 
> It also means it can be used for new checks before all the bugs (and
> false positives) have been fixed.
> I did think of just enabling the checks for W=1 builds, but that makes
> it far to hard to enable them.
> As it is you can use W=ce to enable them and stop on warnings and errors.
> 
> Also W=xxx can only really add checks (there are some checks for it being
> non-empty). Documenting that W=x stopped the 'x' checks being done
> would be painful.

Yeah, I don't think we should be overloading the meaning of W=.

> > Can you please explicitly mention warnings included in W=c vs W=1? Can
> > you report compilation time for W=0, W=1 and W=c? What if one needs to
> > enable fast/slow warnings from 2nd or 3rd level? Would W=2c or W=3c
> > work in this case?
> 
> The W=123 options are all completely independent, my W=c is the same.
> I'm not sure it is sane to run W=2 rather than W=12, but it is allowed.
> 
> I made W=1 imply W=1c so that the build bot would pick up the extra checks.
> Apart from that all the 'W' flags are independent.
> W=123 fiddle with the command line -W options and set -DKBUILD_EXTRA_WARN[123]
> so that files can include extra checks.
> W=c just sets the equivalent -D option.

Why even have a different option then? You mention above placing the
checks in W=1 makes them too hard to enable but then you say that you
made W=1 imply W=c?

> > What does this 'c' stands for?
> 
> Anything you want it to :-)
> Discussion session arranged for 2pm-5pm by the bike shed.

W=c already exists, it is documented as enabling extra Kconfig checks in
'make help'. Maybe W=x for "ex"pensive checks? Or maybe if we really
want W=c, maybe rename W=c to W=k for Kconfig? I do not really have a
strong preference.

> In some sense it is 'more warnings than default, but not as many as W=1'.
> Like a lot of the W=1 warnings I wanted to be able to pick up 'code quality'
> issues without breaking the build for normal people.

So something like a W=0.5? :)

> There are definitely some other checks that could be relegated to W=c
> once it has been added.
> 
> I'd also like to add some checks to min_t/max_t/clamp_t to pick up the
> worst of the dodgy/broken code without having to get all the patches
> accepted before the test itself is committed.
> Tests for code like clamp_t(u32, u64_val, 0, ~0u) (yes there are some)
> tend to get very long and may be problematic if enabled by default
> (I got burnt by the 10MB expansion of nested min().)

I do not have a super strong opinion about this overall but it feels
like this is a bit of a slippery slope with warning fragmentation. I
think I would rather see these be treated like regular compiler warnings
where the majority of instances are cleaned up then it is added to W=1
to keep the tree clean.

Cheers,
Nathan

Powered by blists - more mailing lists