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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <8dbb505a-8ad8-444e-a1f9-1578d76b8d44@meta.com>
Date: Fri, 19 Dec 2025 16:05:33 -0500
From: Chris Mason <clm@...a.com>
To: Theodore Tso <tytso@....edu>, Julia Lawall <julia.lawall@...ia.fr>
Cc: "Paul E. McKenney" <paulmck@...nel.org>,
        Gabriele Paoloni <gpaoloni@...hat.com>,
        Steven Rostedt
 <rostedt@...dmis.org>,
        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>,
        Sasha Levin <sashal@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: Follow-up on Linux-kernel code accessibility

On 12/19/25 12:09 PM, Theodore Tso wrote:
> On Fri, Dec 19, 2025 at 07:51:47AM +0100, Julia Lawall wrote:
>>
>> Maybe we're not looking for an instant understanding methodology.  Rather
>> a machine checkable way to document the invariants that exist in the head
>> of the developer, and for some bounded amount of time in the head of the
>> person who has tried to reconstruct them.
> 
> One of the things that I found really interesting with Chris Mason's
> kernel review prompts is that it documents some of these invariants
> which are not otherwise covered in the kernel documentation.  And
> while Chris originally created those prompts for Anthropic's Claude
> LLM, we've successfully used them with Gemini 2.5 and 3.
> 
> I wonder if we should consider folding them into the kernel sources,
> so they can be updated alongside the kernel.  It might also mean that
> as the invariants change, the documentation / prompts in an LTS kernel
> and for the latest upstream kernel can be up to sync with the relevant
> kernel versions.
> 

Yeah, I agree.  I think/hope these details from the prompts can end up
folded into the kernel docs.  As the prompts age, we're going to have
the equivalent of sprinkling ifdefs into them, and I think it's much
better if they just reference knowledge in the kernel.

I recently pushed out changes that remove most of the process and focus
more on kernel internals.  So hopefully over time we can get to
something that just documents kerneling in a way that is useful beyond
LLMs.

-chris