Re: AI slop (was Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP) policy check

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Thu, Aug 06, 2026 at 02:28:30PM -0500, Gregory Price wrote:
> On Thu, Aug 06, 2026 at 06:42:49PM +0100, Lorenzo Stoakes (ARM) wrote:
> > On Thu, Aug 06, 2026 at 12:40:16PM -0500, Gregory Price wrote:
> > >
> > > mm gets everything
> > > mm-review is curated from mm to reduce noise
> > >
> > > Maybe would have to leverage a model though to surface critical things.
> > >
> > > Just an idea.
> >
> > No I don't want slop going anywhere, at all. Nothing.
> >
> > If you slop the reward should be silence ideally. And certainly not anything you
> > slopped going to any kind of branch... :)
> >
> > The slopularity is upon is Gregory. Behold the desert of the real etc.
> >
>
> I understand the sentiment, but then we have to reduce this to practice.
>
> And unfortunately, I'm about 99% sure that identifying slop is rapidly
> going to approach undecidability.  We're lucky it still emits em-dashes.

Well this is exactly why I think the trust model is literally the only
feasible one.

If you're unknown/known but -> slop then >/dev/null.

It's the only thing that's going to work.

And you build trust by doing small patches and review. Yes that can be
slopped but until AI becomes indistinguishable from a human (which would
eliminate the problem anyway) there's a human and there's a not-human way
of doing that.

Important that the trust can go the other way if bad behaviour is observed.

>
> Unless we plan on converting the list to semi-public (which feels the
> anti-thesis of Linux), i'm not sure how you get there from here.
>
> So the risk is - do you over-bury and make it invisible, knowing we'll
> miss legitimate bugs and fixes - or do you do something (anything) that
> helps you ignore it while still being inspectable and curated.

Trust model should solve that too. If a good faith established individual
or company submits valid bug reports then fine.

And hopefully we'll have some sensible means of handling passive bug
reporting (which emphatically is NOT the hateful sashiko 'this isn't
related to the patch but' stuff) and motivated parties to make the AI stuff
work but under maintainer control.

Because burnout was a thing and now it's what's going to happen to EVERY
kernel maintainer unless pretty drastic steps are taken IMO.

>
> And burning tokens to fight tokens is just blatantly a losing battle.

Yep, not going to work long-term.

>
> ~Gregory

--
Cheers, Lorenzo