From: Lorenzo Stoakes <ljs@kernel.org>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>,
Nick Huang <sef1548@gmail.com>,
Vlastimil Babka <vbabka@kernel.org>,
Harry Yoo <harry@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Jonathan Corbet <corbet@lwn.net>, Hao Li <hao.li@linux.dev>,
Christoph Lameter <cl@gentwo.org>,
David Rientjes <rientjes@google.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Shuah Khan <skhan@linuxfoundation.org>,
linux-mm@kvack.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] docs: Add overview and SLUB allocator sections to slab documentation
Date: Sun, 19 Apr 2026 14:17:17 +0100 [thread overview]
Message-ID: <aeTTw4gziJigaNbU@lucifer> (raw)
In-Reply-To: <c113f667-f897-42cc-a0e5-b8a0bbd91be3@kernel.org>
On Sun, Apr 19, 2026 at 10:35:44AM +0200, David Hildenbrand (Arm) wrote:
> On 4/18/26 18:15, Matthew Wilcox wrote:
> > On Sat, Apr 18, 2026 at 10:07:22AM +0100, Lorenzo Stoakes wrote:
> >> On Sat, Apr 18, 2026 at 12:06:19AM +0000, Nick Huang wrote:
> >>> - Add "Overview" section explaining the slab allocator's role and purpose
> >>> - Document the three main slab allocator implementations (SLAB, SLUB, SLOB)
> >>
> >> The fact you're insanely wrong about the current state of slab only makes this
> >> worse.
> >
> > This is actually a new low. We've always had to contend with people
> > putting up outdated or just wrong information on web pages, and there's
> > little we can do about it. Witness all the outdated information about
> > THP that's based on code that's been deleted for over a decade.
> >
> > But now we've got AI trained on all this wrong/ out of date information,
> > and, er, "enthusiasts" who are trying to change the correct information
> > in the kernel to match what the deluded AI "thinks" should be true.
> >
> > Let that sink in.
Ugh ye gawds. My attitude is nip this in the bud early.
I'm very harsh in response to these things for a reason - firstly, it's rude,
obnoxious + disrespectful, so a negative response is wholly appropriate.
But more importantly, I want to SET A PRECEDENT that if you send this crap
you'll get a VERY negative response.
Clueless but good faith or bad faith - it's straight up plagiarism and that's
totally unacceptable.
> >
>
> I think we should make it very clear that we don't want doc updates from someone
> that is not a renowned expert in that area or wants to become an expert in that
> area (and already discussed working on the docs with maintainers/experts).
>
> Otherwise we'll have this same discussion over and over again.
>
> diff --git a/Documentation/mm/index.rst b/Documentation/mm/index.rst
> index 7aa2a88869083..8c5721001c8bb 100644
> --- a/Documentation/mm/index.rst
> +++ b/Documentation/mm/index.rst
> @@ -7,6 +7,11 @@ of Linux. If you are looking for advice on simply allocating
> memory,
> see the :ref:`memory_allocation`. For controlling and tuning guides,
> see the :doc:`admin guide <../admin-guide/mm/index>`.
>
> +A lot of documentation in this guide is still incomplete. If you are not
> +a renowned expert in the specific area, but you want to contribute bigger
> +chunks of documentation, talk to the respective MM experts first. LLM
> +generated slop from non-experts will be rejected without further comments.
> +
> .. toctree::
> :maxdepth: 1
>
>
>
> LLMs are just the tip of the iceberg. It will all be developmend-by review with
> inexperienced contributors. And we are only willing to put in the effort to
> teach contributors if the contributors are not actually worth our time: i.e.,
> LLM kiddies that will actually stick around and help the subsystem in the long run.
>
>
> The whole doc update stuff is similar to people just grepping for TODOs in the
> kernel and then using an LLM to produce code they have no idea about.
>
> It's the evolution of typo fixes: review load without any benefit.
Agree with all of that!
Let's do that, happy to give tags on a patch for the above :)
>
> --
> Cheers,
>
> David
>
Cheers, Lorenzo
prev parent reply other threads:[~2026-04-19 13:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-18 0:06 [PATCH] docs: Add overview and SLUB allocator sections to slab documentation Nick Huang
2026-04-18 5:04 ` Matthew Wilcox
2026-04-18 5:27 ` Nick Huang
2026-04-18 6:12 ` Nick Huang
2026-04-18 9:11 ` Lorenzo Stoakes
2026-04-18 11:00 ` Nick Huang
2026-04-18 11:20 ` Vlastimil Babka (SUSE)
2026-04-18 15:30 ` Harry Yoo (Oracle)
2026-04-18 6:19 ` Harry Yoo (Oracle)
2026-04-18 9:07 ` Lorenzo Stoakes
2026-04-18 16:15 ` Matthew Wilcox
2026-04-19 8:35 ` David Hildenbrand (Arm)
2026-04-19 13:17 ` Lorenzo Stoakes [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aeTTw4gziJigaNbU@lucifer \
--to=ljs@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=cl@gentwo.org \
--cc=corbet@lwn.net \
--cc=david@kernel.org \
--cc=hao.li@linux.dev \
--cc=harry@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=rppt@kernel.org \
--cc=sef1548@gmail.com \
--cc=skhan@linuxfoundation.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox