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: <20260111033040.GA52543@macsyma.local>
Date: Sat, 10 Jan 2026 19:30:40 -0800
From: "Theodore Tso" <tytso@....edu>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: "Paul E. McKenney" <paulmck@...nel.org>,
        "Dr. David Alan Gilbert" <dave@...blig.org>,
        Julia Lawall <julia.lawall@...ia.fr>, Sasha Levin <sashal@...nel.org>,
        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 Fri, Jan 09, 2026 at 09:58:58AM -0500, Steven Rostedt wrote:
> 
> OK so this is part of the contention here. This thread turned slightly away
> from the original topic and moved towards the importance of commenting
> code, at least for me. But if you were still discussing this as a
> requirement document of some kind, then the comment on the "3" is out of
> scope.

Looking at the original context of of the first message[1] in this
thread, the thesis statement of Paul's message was that commenting
code was *not* a viable way of enabling who want to do "random dives"
into kernel code to understand it.

[1] https://lore.kernel.org/r/90d56d30-232d-4930-ad9f-5aebade7cdf2@paulmck-laptop

Quoting from that first message:

    "The Linux kernel's mm system weighs in at about 200KLoC, and Lorenzo
    wrote a book on its design that weighs in at about 1300 pages, or
    about 150 LoC/page.  This suggests that the Linux-kernel scheduler,
    which weighs in at about 70KLoC and has similar heuristics/workload
    challenges as does mm, would require a 430-page textbook to provide a
    similar level of design detail.  By this methodology, RCU would require
    "only" 190 pages, presumably substituting its unfamiliarity for sched's
    and mm's deeply heuristic and workload-dependent nature.

    Sadly, this data does not support the hypothesis that we can create
    comments that will provide understanding to people taking random dives
    into the Linux kernel's source code.  In contrast to code that is closely
    associated with a specific type of mechanical device, Linux-kernel
    code requires the reader to possess a great deal of abstract and global
    conceptual/workload information."

Steven, you may disagree with this conclusion, but speaking
personally, everything that I've read on this thread strongly confirms
it.

I am not sure that we can count on LLM's to provide reliable "active
software assistance", although a recent experiment, where I enabled
Gemini 3's "deep research" mode, and asked it the question, "How much
money do most software engineers need to retire?", resulted in a 15
page report[2], with footnotes, so you could verify whether or not the
LLM was halucinating or not --- and it was much better than I
expected.  I'm not sure I agree with all of it, but it's better than
many of the YouTube financial advice videos out there.  :-)

[2] https://docs.google.com/document/d/1EDqC-qnHkEyEeewXFx4PuL4VtnC_LxPZ2CKlleB7QBc/edit?tab=t.0

Thta being said, there's a big difference between retirement planning
and trusting a LLM to be able to explain the finer points of say, an
I/O scheduler, the MM's OOM Killer hueristics, or RCU.  I suspect
there are no silver bullets here.

Cheers,

						- Ted