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: <2e7e11cc-907c-47b2-8308-342b52e784c0@lucifer.local>
Date: Tue, 6 Jan 2026 18:08:38 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Chris Mason <clm@...a.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 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.

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

Cheers, Lorenzo