From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 410D432FA34 for ; Tue, 3 Feb 2026 11:14:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770117258; cv=none; b=li2D2R0/AZIlPo/o3j+0gGGoGoonkTJwpgZQr4EV6PERzwn2Q7L5n84MTiSD86H8pEOlJXxpSTx5fde5pQgEJpLg1uvShYNCA4t9J1cB6tdSQlGqgCckXBOQByTWwVQzhMg7iXEN1/NYjEtVE+IYtY6MkpXy8J4o4V51fyW0LAY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770117258; c=relaxed/simple; bh=TGZHFs+y5PZEiI0dxc1o5jYsv5t57JErrTDo5l+CpR8=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=rZU/Taldo4NucxDGk9aD5r/YtQ1u/QdbDWSDF5E4RP1kizqp1Xp9JyPBWDa/i4I7PARiF9IXEIKFtxPCINX7xK/avfUKDv6zGtQFkVV0aZ1ZngYHsxa46xmlMnIdDT43C4zIJsPGNFTS3lkDhUZRiWZWb6jbKEUgAWyhdzlRo3Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Tom3Y4nY; arc=none smtp.client-ip=209.85.221.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Tom3Y4nY" Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-42fb0fc5aa9so3763606f8f.1 for ; Tue, 03 Feb 2026 03:14:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770117256; x=1770722056; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=adwbTe5M7kxA5p3EcIAVpKLTNbIPukeDa7ym8Wf5u6g=; b=Tom3Y4nYl7ndjmQl1+HY0MiEtYUfF8aY0Gvv7QlUBU3GfdbIVeG9V/Y7UVYmnljRp1 PURDcD+fytyNzEPJT4bPzpMltxrAvWQRtq2aIA+oYH9fvRPYrd4RKLPyfrUGKrtozM1k 4bHKMJmx4EFyO9GDrlujAyFOVpe2NtFq2jWyBip8OD1FCAuFKqj2Cl/FarHhJCCm9bHG g/C4fDVZZhMVLy9aM76A5gBJPOVsZ4TkOM8l9xLCpLqdAl4GQnTu4Sm7sVKWagMHCYoj SxpinmrjCob0FuDFZ7vwjfTV5tv4C2T81EfCZqbiirH+BRFcE+DY87ydDJjfHucjm+dL Nobw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770117256; x=1770722056; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=adwbTe5M7kxA5p3EcIAVpKLTNbIPukeDa7ym8Wf5u6g=; b=QvpLeGDm7jGgdtLycmDou1SzrkUtv7AXOCLAl4dvYpVPdFeSZpYgFF1jcR30WumSmQ CjD0NEpdEHC8T0Kdd3ns1ECoJH6oYgTCg9DVnfgU45cKevDIozn2BVxAczfdqglD2XDP TL+juD0+Qe3R8dN6ujSzlHLNIdVj4doahVgim1ip86QJfeD9Guf8RedT3Y78UBVt0qVP aQ+2iU+6fPVvD5cL4PZqlLImlSjfMD+mYeYqOXhj6Oh6r3IvOTk0cvmnoggnbZShVmol FItPHugsrD6gCSXuHkM+qOUPHc/7gG5flCVZtTmbLacKe2XLDhiLJpVcumS8NA7FmUN1 6P5g== X-Forwarded-Encrypted: i=1; AJvYcCX/NHiHLR67AOPHokB+HnRuxuDt+Fb6jofOKjrvUF9uLxhcT49KHjtUgvsOe+IT7FwNlbLObWUVRwrnlT0=@vger.kernel.org X-Gm-Message-State: AOJu0YxwEB3ww1Pzeukiwl+clliNCxsMAvjK+Of3OvBtsTDNKhzDwEFQ adm0QaeqmbpGI1PcxOukZEhX5jeLaOlHGKTeeoNWAAt3TQHz5V1ES3aoOCpjQQ== X-Gm-Gg: AZuq6aIgepVrTWjK7ACUaTZQoisZjjf+QsPFbufsYGzLQBtzzasSqbXFKpOdBL+SvuS mN1F0rNSJ9alE9dQPl1MRBxqvbIOK1uAkynN+OpUqOPblL9cjUAVoBovsHX4jTRQa81YRgJV0ub g7kYRgSWi2C/Fbg9YoTle0xq8Kya8vefs671y2JR7s8ajUt2hCqvOQTrwa1kLmu9MIaOy2MKxhN 43esDa8X4BmKV5guTEjq9pm9N6bYgRay71jArruKCNQ8q58O6TbBOT3xTw2DkiyPGV1IqppxueN lOQ8qBhtjl+PUaI2SHg3DNqa892Tr79z9RzUlh9vfNCrjKRX2K7Gw5rFKsA6PpoMBVT2/kE5/1W EPOS+zeleiCyYGvQS+D5Ev+3CX4msFpP6GLdsM3KkJbmgw4hLmrhJTutK2cltTcyJE4vMnfc5Md kIKccpFs34ryydHk0jCNNj4UPheNLsSBUlL55RhdwzcFZqJJcpzy/x X-Received: by 2002:a05:600c:a00e:b0:477:63db:c718 with SMTP id 5b1f17b1804b1-482db4bda8dmr203947335e9.16.1770117255417; Tue, 03 Feb 2026 03:14:15 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e10f82aesm53083817f8f.19.2026.02.03.03.14.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Feb 2026 03:14:15 -0800 (PST) Date: Tue, 3 Feb 2026 11:14:13 +0000 From: David Laight To: Nathan Chancellor Cc: Yury Norov , Greg Kroah-Hartman , Thomas Gleixner , Peter Zijlstra , Ingo Molnar , Mathieu Desnoyers , Arnd Bergmann , linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, Yury Norov , Lucas De Marchi , Jani Nikula , Vincent Mailhol , Andy Shevchenko , Kees Cook , Andrew Morton Subject: Re: [PATCH next 02/14] kbuild: Add W=c for additional compile time checks Message-ID: <20260203111413.7cf29fa3@pumpkin> In-Reply-To: <20260203044726.GA3049363@ax162> References: <20260121145731.3623-1-david.laight.linux@gmail.com> <20260121145731.3623-3-david.laight.linux@gmail.com> <20260202200743.6182eb60@pumpkin> <20260203044726.GA3049363@ax162> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 2 Feb 2026 21:47:26 -0700 Nathan Chancellor wrote: > On Mon, Feb 02, 2026 at 08:07:43PM +0000, David Laight wrote: > > On Mon, 2 Feb 2026 13:33:22 -0500 > > Yury Norov wrote: > > > > > On Wed, Jan 21, 2026 at 02:57:19PM +0000, david.laight.linux@gmail.com wrote: > > > > From: David Laight > > > > > > > > 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 > > > > > > 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? IIRC a couple of %. I repeated a few builds with/without and it was much greater than the variation between the builds. That is a pretty trivial test, but there are a lot of READ_ONCE(). Find a few of those and the difference is significant. > > > 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=. I did thing of supporting W=-e so that you can do W=1-e on a config that enables WERROR, since there isn't much chance of a W=1e build succeeding any time soon. > > > 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 I meant was it is hard to see the errors in a W=1 build. So I wanted the enable the checks without picking up W=1. > > > > 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. It was 'c' for Compile time (a bit silly - but they are source 'compile-time' tests rather then 'run-time' ones). I'd only looked in makefile.warn for other uses. > > 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? :) That is really what I was looking for. Perhaps setting -DKBUILD_WARN_LEVEL=level*10 would do? So W=1 would set 10, W=2 20 (etc) with some scheme for setting intermediate values (or at least (say) 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. That is slightly different because (mostly) they are warnings from a new compiler version so are picked up by people running the new compiler before they break things and then added to W=1. Adding an extra check to an existing header needs the change committing to get test coverage somewhat earlier - maybe to force some reluctant maintainers to actually fix their code. I definitely needed to conditionally include the checks with W=e but without W=1, this seemed the best way to do it. David > > Cheers, > Nathan