linux-kernel - Re: [RFC PATCH 0/4] Enable Clang's Source-based Code Coverage and MC/DC for x86-64

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251015092145.GB3419281@noisy.programming.kicks-ass.net>
Date: Wed, 15 Oct 2025 11:21:45 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Chuck Wolber <chuck@...ber.net>
Cc: Sasha Levin <sashal@...nel.org>, nathan@...nel.org,
	Matt.Kelly2@...ing.com, akpm@...ux-foundation.org,
	andrew.j.oppelt@...ing.com, anton.ivanov@...bridgegreys.com,
	ardb@...nel.org, arnd@...db.de, bhelgaas@...gle.com, bp@...en8.de,
	chuck.wolber@...ing.com, dave.hansen@...ux.intel.com,
	dvyukov@...gle.com, hpa@...or.com, jinghao7@...inois.edu,
	johannes@...solutions.net, jpoimboe@...nel.org,
	justinstitt@...gle.com, kees@...nel.org, kent.overstreet@...ux.dev,
	linux-arch@...r.kernel.org, linux-efi@...r.kernel.org,
	linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-trace-kernel@...r.kernel.org, linux-um@...ts.infradead.org,
	llvm@...ts.linux.dev, luto@...nel.org, marinov@...inois.edu,
	masahiroy@...nel.org, maskray@...gle.com,
	mathieu.desnoyers@...icios.com, matthew.l.weber3@...ing.com,
	mhiramat@...nel.org, mingo@...hat.com, morbo@...gle.com,
	ndesaulniers@...gle.com, oberpar@...ux.ibm.com, paulmck@...nel.org,
	richard@....at, rostedt@...dmis.org, samitolvanen@...gle.com,
	samuel.sarkisian@...ing.com, steven.h.vanderleest@...ing.com,
	tglx@...utronix.de, tingxur@...inois.edu, tyxu@...inois.edu,
	wentaoz5@...inois.edu, x86@...nel.org
Subject: Re: [RFC PATCH 0/4] Enable Clang's Source-based Code Coverage and
 MC/DC for x86-64

On Wed, Oct 15, 2025 at 08:26:50AM +0000, Chuck Wolber wrote:

> > I'm thinking I'm going to NAK this based on the fact that I'm not
> > interested in playing file based games. As long as this thing doesn't
> > honour noinstr I don't want this near x86.
> 
> I am working on a noinstr patchset that will precede this pachset. As it turns
> out there are several areas of the kernel (128 that I have found so far) that
> are missing the noinstr attribute macro.
> 
> Example:
> 
> kernel/locking/lockdep.c:
> 	void noinstr lockdep_hardirqs_off(unsigned long ip)
> include/linux/irqflags.h:
> 	static inline void lockdep_hardirqs_off(unsigned long ip) { }
> 
> The latter version is intended to be optimized out if the kernel is not
> configured to use this feature. However when the kernel is instrumented for
> profiling, the stub is not optimized out and ends up in the .text section
> rather than the .noinstr.text section.

Typically we switch to __always_inline when this happens. Ideally
though, compilers should strive to not be stupid and instrument dead
code to the point where DCE will fail.

> > And we have kcov support, and gcov and now llvm-cov, surely 3 coverage
> > solutions is like 2 too many?
> 
> Optimization makes it nearly impossible to correlate GCov results back to
> actual lines of source. llvm-cov instruments at the AST level which enables
> precise mapping back to source code regardless of optimization level.
> 
> 
> A detailed rundown on this issue can be found here[1], with the most relevant
> excerpt reproduced here:

Yes read and understand this, but that doesn't mean you have to have 3
different kernel interfaces for all of this, right?