Re: [PATCH next 02/14] kbuild: Add W=c for additional compile time checks

[Yury Norov <ynorov@nvidia.com>]

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@nvidia.com> wrote:
> 
> > On Wed, Jan 21, 2026 at 02:57:19PM +0000, david.laight.linux@gmail.com wrote:
> > > From: David Laight <david.laight.linux@gmail.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@gmail.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.  
> 
> 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.

Please don't speculate for what others want. I already said very clearly
what I (probably) want - a performance-aware set of warnings. I can tell
you for sure what I do not want - a heavyweight subset of W=1 with a
partial coverage and similar compile time.

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

It is allowed and sane.

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

Again, please:
 - list all warnings included in W=c and their performance impact;
 - report build time for W=1 vs W=c vs plain make;
 - how would your new option work with W=2c, W=3c and so on.
 
> > What does this 'c' stands for?
> 
> Anything you want it to :-)
> Discussion session arranged for 2pm-5pm by the bike shed.

Meaningless parameter names are not welcome. NAK.

> 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.
> 
> 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().)