public inbox for linux-mm@kvack.org
 help / color / mirror / Atom feed
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


  reply	other threads:[~2026-04-19 13:17 UTC|newest]

Thread overview: 14+ 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]
2026-04-20  4:52         ` Nick Huang

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