From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 767954D2ED3 for ; Thu, 6 Aug 2026 19:34:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786044853; cv=none; b=FfJtXg9Dj+oxNvT4x6PWSDUIryan3hEyP0caWIJLmCGYtFvijiLKgkZDqeupHvsVB+2L5+vgEnRT5hYAC/OHhfpqOwbyD3fIeLkm+MCBxFX63ce3C0julbQJhr7xrt0UsFV/uInaqXe69nRsjzLqyznfda1sS+25RDzEpipGp90= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786044853; c=relaxed/simple; bh=3ybX31zdKfYCk5wqrTvh6kBGrh/QaKaE3Zk/S9b/U8w=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=TE5iMQYoxZjQJScBf/TPpuFTzKHnceVlAj0hRYX7zurQbQZz5NkdGVus06eWY3ra72y3KO4l5EDwRKY1GJKI4Gh+Co7r9Vde8iUgAnqIhyQvBSbkri36JXc2vWBXH9XkTrNfoYFQCKRDMD7chIuzWjhIGS2+OI2YaCCDRA01jkc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mL6pNyHr; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mL6pNyHr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 27A1C1F000E9; Thu, 6 Aug 2026 19:34:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786044851; bh=qYG4uYlSwucrFSr89w+VCACONAMfUo5j46PTWngTyLk=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=mL6pNyHrLww6c0XxczPgoBKZaZvJDU5y4ZZ79xVCURng3I1Hw/3xMzOQYSBP/0I+o opuispy05cZ4llIgDSHIRn0ZDU0EsHjo93BbSpglhDP2j2AqL+E/ctpBCelO6ONFQz 1F/nPM9WuQ63FhIbjJ+rmAzXKA84VKwdwm3YQ6J/RvhQKFS3GNHgHmW7/oFhIZbwCt 88jMIhx8LkSFN+PakMBvvfOCWNXfHOKV6/R98F1zlANTdz6TCe5rJPYL+KRaKRLhG+ D8mx6JOjD7dgudXjoUO7SMg32uv0a87Pwxe83fjNhZDmqupZYmpQCLWcUWYJ67jljz 3QFsqeteEEdgA== Date: Thu, 6 Aug 2026 20:33:54 +0100 From: "Lorenzo Stoakes (ARM)" To: Gregory Price Cc: Zi Yan , John Hubbard , Jason Gunthorpe , "David Hildenbrand (Arm)" , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: AI slop (was Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP) policy check Message-ID: References: <5b7e84f5-2007-458c-910f-7a6e1e3d3eab@redhat.com> <20260806164517.GA140051@nvidia.com> <10b07d00-57e5-499b-a136-f2148e870d9b@nvidia.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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