linux-kernel - Re: Follow-up on Linux-kernel code accessibility

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <89457d2d-153e-4274-b485-2ace983cec4f@paulmck-laptop>
Date: Tue, 23 Dec 2025 15:46:10 -0800
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Sasha Levin <sashal@...nel.org>, Theodore Tso <tytso@....edu>,
	Julia Lawall <julia.lawall@...ia.fr>,
	Gabriele Paoloni <gpaoloni@...hat.com>,
	Kate Stewart <kstewart@...uxfoundation.org>,
	Chuck Wolber <chuckwolber@...il.com>,
	Dmitry Vyukov <dvyukov@...gle.com>,
	Mark Rutland <mark.rutland@....com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
	Shuah Khan <skhan@...uxfoundation.org>, Chris Mason <clm@...a.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Follow-up on Linux-kernel code accessibility

On Mon, Dec 22, 2025 at 10:42:09AM -0500, Steven Rostedt wrote:
> On Fri, 19 Dec 2025 16:36:33 -0800
> "Paul E. McKenney" <paulmck@...nel.org> wrote:
> 
> > > This is one of the motivations I have for modeling the complex portions of
> > > the tracing subsystem. I'm hoping that I can see better ways to perform
> > > these tasks and possibly even improve its performance.  
> > 
> > If there are 100,000 function-like things in the kernel, and we add 100
> > lines of comments to each, we will have expanded the kernel source by
> > some tens of percent.  Plus staleness and/or churn will likely be problems.
> 
> I'm really only interested in the more subtle and complex functions. The
> majority of those 100,000 functions do not need extra comments.

Sigh.  "Subtle" and "Complex" are rather subjective, and given the
goals of one of the LPC MCs, others outside the community might decide
to weigh in.

> And I honestly don't care about increasing the source due to comments.
> That's a good thing. I like going to a subsystem and seeing a lot of
> comments in the code. I hate going to a subsystem where there's no
> comments, thus you need to try to figure out the context from the code, and
> when I had that, I usually got it wrong.

I do care.  After all, life got much better when (mostly) ineffective
"Only invoke this function with interrupts disabled" comments became
"lockdep_assert_irqs_disabled()" executable code.

So if we are going to add more explicit constraints in header comments,
we owe it to ourselves to see what can be made executable so that
normal testing has at least some chance of detecting violations of
these constraints.

> > Yes, it helped you, and that is good.  But is this really the best way to
> > achieve that goal?  Better than human walkthroughs?  Than querying LLMs
> > that ingested the code?  Better than producing external documentation
> > at the design/code level?
> 
> So far I've not been too happy with the results of LLMs describing code.
> They tend to come up with the same mistakes I do when I try to figure out
> what the author of the code was doing by looking only at the code without
> any comments that came from said author.

Fair enough.  I am not entirely satisfied with the LLMs myself.
Then again, I am also not entirely satisfied with the output of humans.
But so it goes.

What about walkthroughs?  Producing external documentation based on
the code?

							Thanx, Paul