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

Message-ID: <da6a9e9e-059a-440c-9261-eb3355f6a84d@meta.com>
Date: Tue, 13 Jan 2026 08:03:51 -0500
From: Chris Mason <clm@...a.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Theodore Tso <tytso@....edu>, Julia Lawall <julia.lawall@...ia.fr>,
        "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>,
        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 1/6/26 1:08 PM, Lorenzo Stoakes wrote:
> On Fri, Dec 19, 2025 at 04:05:33PM -0500, Chris Mason wrote:
>> 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
>>
> 
> I think we have to be super cautious about ensuring that any such output is
> correct.
> 
> To me the system is assistant-to-an-expert.
> 
> Adding a bunch of invariant details including very subtle (or otherwise)
> bugs is worse than having no such documentation.
> 
> I say this with a far more broad and open-minded impression of AI tooling
> in relation to review and the kernel in general by the way - I'm just
> keeping things real here.
> 
> Maybe the answer is we need a R-b for any such output from maintainers with
> appropriate expertise.

I agree with all of the above, and my goal for the prompts was always to
have the subsystem specific prompts owned by the subsystem itself.  If a
particular subsystem isn't interested, I'd either limit it to obviously
correct details or just not run reviews against those commits.

We're not quite there yet, but both scheduler.md and nfs.md were
contributed by respective maintainers, and the bpf and block details
were reviewed when they went in.

LLMs end up consuming these docs the same way people do, so all the
debates about where to put documentation (inline comments? doc files?)
apply the same way.  I think the review automation is a good excuse to
talk about this for individual subsystems, and hopefully the automated
reviews can help subsystems keep whatever documentation scheme they
choose up to date.

> 
> Thanks for the work you're doing on review by the way Chris! Is promising
> :)

Thanks!  I'm doing another MM run this week, so you'll soon have a
chance to give feedback ;)

-chris