From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3787A1CAB3;
	Mon,  8 Sep 2025 22:15:55 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.173
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757369757; cv=none; b=GQxk6MkKafmycpEq22BtG8l/t1743X85xKJoT0zR2AchSGLx3YlDasQ4zgPHq4nsah36dRAGwkfpzstHJtOcV0FRsMPDcN2bXdWltBEsCaAUw62KtThyh9jtQut8B7xzPoP9ugig2Pyfo/SQBhfHKU9TA1D5osx7TjSHUSxoKAU=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757369757; c=relaxed/simple;
	bh=RwQ7UCz527ifaP8+Sv/1V2E2KJyy2+JYcgwQhQSMazI=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=kK9gM8ILZiXLPS4mYL1s3jKyht0c4usxQDqFhBdbxLJlzl5/FX2AwY7o9VteGhekWTrrWYVhpueOJlrNw8e5oYNlZq7sCcuIYtPErswrbRN0Gr5XXUklrlUbhctKQ+PdKm9eNXyid4eujq769XnEGnN0fHU9mSiiDS1S+DetuGg=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=O2rj+UlI; arc=none smtp.client-ip=209.85.214.173
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="O2rj+UlI"
Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-2445824dc27so48838625ad.3;
        Mon, 08 Sep 2025 15:15:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757369755; x=1757974555; darn=vger.kernel.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=XmleHkclN2N7xiK207HC2jo02VYu1gJHqknqPHZCHKY=;
        b=O2rj+UlI+xDDotrfyFzqsVimAPeXlZdu/NizeFQkIYPH6VkSresx0dn5k5ONNQNZSL
         G7bsGn2Wyk9NnQ86N0atfMCsNpxHCWjgrE/ziIadHOAbUGSzWUjqaDs4z0l2Yp27Kpiu
         QaVBuanPO0LLDVc1m3OTdwnz2f3fQyGDUHH+PtBfANvE/n4pA7+f8q/GH9DerN1OQdZO
         0diJ3xs3EipIsJcL7Udujv6vJnpLRhoZXQUKr2+oJ9CYjKtLPGayR3bb9heVwd3mEH1P
         3Xcm1RpE73si/pwof3oaxaQ9olWigWdLVd2mPxFASMjSFyCdGeOhPU8pzrUUvbbdX7tG
         Jmcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757369755; x=1757974555;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=XmleHkclN2N7xiK207HC2jo02VYu1gJHqknqPHZCHKY=;
        b=fpBWkS7hNYmjuwS6o6/OeC47/g62FoH7j4uY3YQVxvIC52jKY5w/8WEPiOrdezeMOy
         /bLyRiEP1+vi1udjdIFUL9vWsi+s3eVbntSqcDTj66gJwVPUFnVPWiSmuGWWjoY5Vjd9
         MXOS2uFUIXUoF/+avZD5hqNnbYD1fThnm7LVJk/KXZDjEQQgs/ghnRUDNN64TdR0lIpg
         aw72Rv5enP5BtVblxME8RtX5weoFLRDYPsoyjiNlBnDLfb6rejyvaqmuIOWOdKGXlX+b
         bdMo+5FKcXcF4qk6rtuNOareNa6c9SSlihz4Ay69+SjKCukI48CkKlyFI+U3E1Yv74jo
         77Xw==
X-Forwarded-Encrypted: i=1; AJvYcCU53SAO/FAi2zAvoGw5Dhphoz1ty+gIJYXcSyztDy0omrzjYsAVIjSFXCfy96KTtIW4Np4=@vger.kernel.org, AJvYcCWhBiJPul2FbsVt7oouT492Lo3atcCzV0jVHxMiFfGWKX8kJ5TXsCkBKcRY3GHP4/QyVURkNzUPXB0=@vger.kernel.org
X-Gm-Message-State: AOJu0YwbYquLh61bku9XCiZgDygnG45gWo0SXOyqeO1EB6Qzk6ma/YXg
	nPrLzzOuO7VtJgMGzzNpXuE6uvGlAAhyXdEDn3VcRcnFWS8W/L2bCJWR
X-Gm-Gg: ASbGnculvKyGxyv2Ru24TkqmaQDtkxbECvy9zVVbrajrc3gygtvnEdAzPQZi1gAa6ID
	Soj96rxrZhp3JlB2+iY5cR53ulmpqh5oo8YwEdUL8BSL+f3K0wARH3cKsGOZ+UiB4+tJlgrO97U
	8XyQl9w3PgZy1qR6JAq5mkt+hclh495wYnP9kT8tVpCM3LokNs1NnNMLfYh6lw5KGQ6AdgI1VLV
	VqX9bOD36sdkg0jzVvbnJhC+KX71kkrh7+2gpoL2HOGhiBrL2jlJAhLfZ+sc0rnWEgRH1wdi7kv
	mdAqISadDW0b9aVOCxP50X8eM5RwSmzc+r2p6pnHArxnKdEkNkNnrY3j+0qySVKz8rkfwcjCxwn
	M/PFuTHXypWSyM6ldlxzrBdNJQ5NPO5nl5AYesXE8qQzP4Dz6u5RuxOj8501HbQ==
X-Google-Smtp-Source: AGHT+IGsWoGRUEg2UW+xk0le/mjW+nq65zly6kSjWr/ClU/xlK6N1ucyeRRCp65bdRfDg0FeSN6JLA==
X-Received: by 2002:a17:902:ef52:b0:251:5f19:c3b1 with SMTP id d9443c01a7336-2516dbf19camr100172555ad.9.1757369755316;
        Mon, 08 Sep 2025 15:15:55 -0700 (PDT)
Received: from MacBook-Pro-49.local ([2001:558:600a:7:44e6:767e:cc5a:a060])
        by smtp.gmail.com with ESMTPSA id d9443c01a7336-2490658999fsm288788275ad.112.2025.09.08.15.15.54
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Mon, 08 Sep 2025 15:15:54 -0700 (PDT)
Date: Mon, 8 Sep 2025 15:15:53 -0700
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>, 
	Caleb Sander Mateos <csander@purestorage.com>, io-uring <io-uring@vger.kernel.org>, 
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>, bpf@vger.kernel.org
Subject: Re: [GIT PULL] io_uring fix for 6.17-rc5
Message-ID: <lxevpprltteumg5r77ekdors6tlpy5vyvxxef737obpluz2u44@vgkpxkcwq76r>
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
 <f0f31943-cfed-463d-8e03-9855ba027830@kernel.dk>
 <CAHk-=wgkgSoqMh3CQgj=tvKdEwJhFvr1gtDbK7Givr1bNRZ==w@mail.gmail.com>
 <72fb5776-0c50-42b8-943d-940960714811@kernel.dk>
 <CAHk-=wgdOGyaZ3p=r8Zn8Su0DnSqhEAMXzME91ZD9=8DDurnUg@mail.gmail.com>
 <a65abd25-69bd-4f10-a8b8-90c348d89242@kernel.dk>
Precedence: bulk
X-Mailing-List: bpf@vger.kernel.org
List-Id: <bpf.vger.kernel.org>
List-Subscribe: <mailto:bpf+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:bpf+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a65abd25-69bd-4f10-a8b8-90c348d89242@kernel.dk>

On Fri, Sep 05, 2025 at 06:01:01PM -0600, Jens Axboe wrote:
> On 9/5/25 2:54 PM, Linus Torvalds wrote:
> > On Fri, 5 Sept 2025 at 12:30, Jens Axboe <axboe@kernel.dk> wrote:
> >>
> >> Like I said, I think there more fruitful ways to get the point across
> >> and this picked up and well known, because I don't believe it is right
> >> now.
> > 
> > So I've actually been complaining about the link tags for years: [1]
> > [2] [3] [4].
> > 
> > In fact, that [4] from 2022 is about how people are then trying to
> > distinguish the *useful* links (to bug reports) from the useless ones,
> > by giving them a different name ("Buglink:"). Where I was telling
> > people to instead fix this problem by just not adding the useless
> > links in the first place!
> > 
> > Anyway, I'm a bit frustrated, exactly because this _has_ been going on
> > for years. It's not a new peeve.
> 
> What's that saying on doing the same thing over and over again and
> expecting different results...? :-)
> 
> > And I don't think we have a good central place for that kind of "don't do this".
> > 
> > Yes, there's the maintainer summit, but that's a pretty limited set of people.
> 
> That'd be a great place to discuss it, however. One thing I've always
> wanted to bring up but have forgotten to, is how I'd _love_ for your PR
> merges to contain the link to the PR that you got for them. Yes I know
> that's now adding a link, but that's a useful one. Maybe not for you,
> but for me and I bet tons of other people. At least if there's
> discussion on it. But hey I'd be happy if it was just always there, but
> it seems we disagree on that part.

+1 to above request.

Regarding Link tag. We've been adding them to all bpf/net commits
for quite some time and found them useful in many cases:

1. patches rarely come as a single patch. Even if it's a single line
fix there is likely a selftest in the other commit. When I investigate
a commit clicking on lore link and seeing the whole series saves a ton
of time, since search by commit name in lore.kernel.org/all/ isn't great.

2. patches rarely accepted on the first revision and we recommend developers
to add lore link to v1 when they respin v2. So by the time vN series
are accepted the cover letter has links to all previous revisions.
Similarly when I debug an issue: git blame, git show sha, click on lore link,
click on 0/N, click on v2-v3, since most of the interesting discussion
happens in earlier revisions. The last few respins will typically address
final nits.

3. even if it's a rare single commit the patch subject doesn't say
whether it was v1 or v2, while lore has this information in email
like [PATCH bpf-next v2] subj. Going to lore and realizing that
ohh it was v2 that was accepted is a lot better than search by subject
and seeing v1, v2, v3 versions of the same patch and not being able
to tell which one was applied.

So the only case where Link is useless is the case of single commit
without any revisions that was accepted on the first try.
We can manually remove such links, but this would be tedious
manual work, since automation is tailored for common case where
link is in every commit and they are useful.


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-yw1-f171.google.com (mail-yw1-f171.google.com [209.85.128.171])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 83BA926AAB7
	for <io-uring@vger.kernel.org>; Fri,  5 Sep 2025 11:18:38 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.171
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757071120; cv=none; b=LGynU0BKMszyTJzmalXyMU7c4NFGcSPn8tlLjPMwbW15rRmHONfI9yechpBgj9kuyygQNYpafp25HnkoPbw2NQ0HTZjF81S0BMO7aAMIUQpsqPaQ6g0BgXP5sTMfayHtVjvKPxdWhUm9lAqiTKWUD05tv9mMvMQjgq5xExp8Hd0=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757071120; c=relaxed/simple;
	bh=8uTORwb3D00xnrSpwfZOhy7bUURRiYs+eOuaQJofs2w=;
	h=Message-ID:Date:MIME-Version:To:Cc:From:Subject:Content-Type; b=J4LMYV6Vji67dhCUYr2+I729dyYbjE8FiAv1PLb2LR15uu0A8QWTPWOeRIn2Goe2VkuJfGPCQlL6gjYbaBiqisqyOwNDTKft0CPx0Mo69C5EgDeNmqYGiGBEv8d+UWbjFpT/3PW1t/Wi1ayUypwIO+Keyrr2/+k2g99PIVG3/jI=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk; spf=pass smtp.mailfrom=kernel.dk; dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b=jBR4rs3e; arc=none smtp.client-ip=209.85.128.171
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kernel.dk
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b="jBR4rs3e"
Received: by mail-yw1-f171.google.com with SMTP id 00721157ae682-71d60501806so20057997b3.2
        for <io-uring@vger.kernel.org>; Fri, 05 Sep 2025 04:18:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=kernel-dk.20230601.gappssmtp.com; s=20230601; t=1757071117; x=1757675917; darn=vger.kernel.org;
        h=content-transfer-encoding:subject:from:cc:to:content-language
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=qYJcA7s0keMR6OUcQiR8GwwIpU35oJtw3RFv33PV/Xc=;
        b=jBR4rs3e44+kHuBvgy8U6j9+9yq36nXXKEDyXG2M9Rr4L+HnOn435TcyHu1VAHGemf
         SeL7Hch2gRmGJ6Q2mMdUz4AMBWP+qjpS5L6S9AH1Vt8H6IwmuYhpdrsGyKTtttaSTC31
         M7sOeXVfiZyy/H2IYRAg+ymDqg8KIugFi/4eHnBky4qvxkBMxpYQlGCDmb+NkpXHaXit
         QIjMAl2Izt7ZQ9nL53X5GEYZ8wv13N3OGc4HFhaLaiEwe3alVeWIkaCLJDfnKqoA3fqX
         3V6UMO8Gm/WELA9s569dOXFK1jqnehader3UEjp49rPq39Vdrmf9kzrSQRaNoqKQ6L9e
         83LQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757071117; x=1757675917;
        h=content-transfer-encoding:subject:from:cc:to:content-language
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=qYJcA7s0keMR6OUcQiR8GwwIpU35oJtw3RFv33PV/Xc=;
        b=g4gcCy3iyKynHc9AiKES7r7PvQYtun3uCkOVxSzUjZ3yhwrQXuqSTw4yG9JcedbfTl
         mBlXWgoUP9Vl7lDKjJF817xrYEVM6cK19Pegi7mHMsSiSNcVetPpoTDpc+cMeBW39oa0
         q8UWQD8cTbgEze5gQXcLq3EJTOrB6hrVBmd2hLHQ7GlrUhdrzcAhV8Qy6HVL5Q7HpzVY
         IVlM+hiYiIQvsfi/T3KbFWa/SXzyyYQm4ghUmgHZz1hPRFQed8n1SK4vgaGuIfMX+3hg
         0b1f23lPVn5RC915EGDBjEmWzuliaOrMAjo3UbgeOpWTKdqeIG3xMpzav/pyB97jPzMu
         zqBg==
X-Gm-Message-State: AOJu0YyWR0GIRj9vBenuJwEKVpF2wnEpV3VcxYBU165n41/daz1k0L35
	ABjDs9HFtSyIs23YHUVxvljYctc8htRtp4AdKzhLXBerfnBEhtELCh7Mgp7js4Kqg+V/pELbW9J
	gZtBW
X-Gm-Gg: ASbGnctk+hOTQc5vTuXbjXSaOi8ylq+Nrwpa4ErIEGRxuiKWny2IqYkFsDzY8VrJuaK
	ylRYXOjVGg77p8VQwNaGKJbFccd3b9XWj+3dQMeUpDH7b5xm3N2m94nkBQlZCfNEsAkM0R1uMp/
	NSXdCOjMNfaR67UmMueJNnCtA14Wfy+oa+ihXWlpgT6GTw3o0IasWF4zuxULqx/fVknY7neKUj3
	JrgbpxBx6cABh+ojVE2QmDEJWtGsAFozf9QWsTmKIGI//zREpKhb59v/IEHaFTam0jG/c2kZFnG
	nyrbN8p0HGL0e7gPBdSPIrJ4DaJMT+5PQYsDf2fToED6OklazYg9iblrAMF3L50yRtuKj+teTYu
	aa4L6T10Y/ONI7wX6kV63JB+2/VJt
X-Google-Smtp-Source: AGHT+IFz8nD9ftFet+N7MFnk8OJxw+yKQq90YTUZ7DpsUk8JBOuEDAq+zECDttqqtH8ffaXgGbYukw==
X-Received: by 2002:a05:690c:630e:b0:71a:300c:d17e with SMTP id 00721157ae682-722763fa90bmr266792237b3.20.1757071117268;
        Fri, 05 Sep 2025 04:18:37 -0700 (PDT)
Received: from [10.0.3.24] ([50.227.229.138])
        by smtp.gmail.com with ESMTPSA id 956f58d0204a3-5ff8784525dsm2295744d50.3.2025.09.05.04.18.36
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 05 Sep 2025 04:18:36 -0700 (PDT)
Message-ID: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
Date: Fri, 5 Sep 2025 05:18:36 -0600
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: io-uring <io-uring@vger.kernel.org>
From: Jens Axboe <axboe@kernel.dk>
Subject: [GIT PULL] io_uring fix for 6.17-rc5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi Linus,

Just a single fix for an issue with the resource node rewrite that
happened a few releases ago. Please pull!


The following changes since commit 98b6fa62c84f2e129161e976a5b9b3cb4ccd117b:

  io_uring/kbuf: always use READ_ONCE() to read ring provided buffer lengths (2025-08-28 05:48:34 -0600)

are available in the Git repository at:

  git://git.kernel.dk/linux.git tags/io_uring-6.17-20250905

for you to fetch changes up to 0f51a5c0a89921deca72e42583683e44ff742d06:

  io_uring/rsrc: initialize io_rsrc_data nodes array (2025-09-04 19:50:33 -0600)

----------------------------------------------------------------
io_uring-6.17-20250905

----------------------------------------------------------------
Caleb Sander Mateos (1):
      io_uring/rsrc: initialize io_rsrc_data nodes array

 io_uring/rsrc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
Jens Axboe


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1EA6F2F7AA4
	for <io-uring@vger.kernel.org>; Fri,  5 Sep 2025 17:24:37 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.53
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757093079; cv=none; b=dL4SKp5u55NaQXjvFnm9grGUgxLLGIX4ayz7bSF4DwZ3CeDa+FUvhrsqlTPTvAepSeLVwMtJbZIS2FLZjspE8+pt/6yXac8wX8Mpa5UrVuev+1VSJOgN4PiIh8hQS7E1x1ug6/5FrcAG3R6DPmPBmybhBvOSt9ApnSu9zvNlV5k=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757093079; c=relaxed/simple;
	bh=OfYKVnMkszh29qi9BY4EJ/L6TXAXUARbdoIeqq75QBA=;
	h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
	 To:Cc:Content-Type; b=A/xbOMBYG3vkaEIYavpHHjAC+GsmbVEHbtxNm542v7nxCPw3uS46SP0tL6bEzKlMrJ5Ci/T/TzO12VSaJbcazySELtTdZh/w1clBTIcqgyQvRqYJ7o+oH7L8HQf/gxD0BMh7BNDCQeFymLh+VBWMPSvnbhOcZwzhl8QuI2Sj29A=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org; spf=pass smtp.mailfrom=linuxfoundation.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=RHuo4QmT; arc=none smtp.client-ip=209.85.218.53
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linuxfoundation.org
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="RHuo4QmT"
Received: by mail-ej1-f53.google.com with SMTP id a640c23a62f3a-b04271cfc3eso319976966b.3
        for <io-uring@vger.kernel.org>; Fri, 05 Sep 2025 10:24:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linux-foundation.org; s=google; t=1757093075; x=1757697875; darn=vger.kernel.org;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=cLgXP0nUuKPljGYi8/jWyq52SSymo18ITef/UKlDP9M=;
        b=RHuo4QmTkWgGnqYSE1DQ6fiRz49238FOn8YfsKJBxcpaDI4SbA3j6TpXUJlnkZ3fLr
         UjkRfqTQttI31DexwfOWuTKG0d5TsqJBAWcU8Rh1Ms7FfZJ+eXfR+OckI/mJdvl7aSuw
         /G3ixmbOmUXs214mErdFyfKdnQVa7371YI3x0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757093075; x=1757697875;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=cLgXP0nUuKPljGYi8/jWyq52SSymo18ITef/UKlDP9M=;
        b=rNljsFN6AuLTlFPSuoSJSvxCndI22bNQznY/q0cDKWLM51MNTdM1IaQk+HWqa02tiM
         0moN49ujmiL7+yauzYfx+DeWCbQ7/Rd+g2d8k564TCtt/ILPGpQyVbG5z0kk6PO0Y5zR
         Td5e6GhNIpZPO+M0haMFXKcAZoEJSeutogwv7uXAVUOACY6V3FfQ+YYmkCbpj2Grb1up
         jlAEhEV8rPBdXGRI/E2leq97a8kOqAF15exNDpAfRLZgAjEf0tc8dA3fvwY7a2+f0TF5
         fxkB9f1XzZSxz4RUzXrzXDmVo/QCh+X/9F2+UvHQ08WFrlA7sqoZ7a6Rn+SCxFV9t0oc
         +khQ==
X-Gm-Message-State: AOJu0YwfuiEzd9gTe94pSDCBMelilCCvEdF+Kw3L6Cu7S2nD68+bKjdn
	537U6H2HrtUqBQ2+86ZtHOXxRRpzCXhTpJ23T/d56xlM4sohvpbT4nLYcCdVg88xjYZ+gtAIAE6
	YhJuGqUQ=
X-Gm-Gg: ASbGncvbEyGD1PVsWhau5VelufMnJ3D1ZyBWJfNpCpLP6vhD8uyJuAAut2qDmg1QB+D
	weJ3AQgKWfk8YMibv2zZcgM7QsractRfzN0SiYESz2VDsu9JwXxVnWeldrfVr5AkOl0SqTgmUD/
	PCNps3FVqMh3aObHuXGJ/65MMVZDDOip6xO4g4nFqZ/h4X6fh8bjkBl1vJVrR+K03eE52HZ+o6c
	508+5AC1A6svdZjtiAB4TXNMeXXP/OiJQ+aHW5rKQ/GYBCIoce54ZdOjVUU7V+W1reKwOs0Q9zc
	Z3NKv8j79bpZ/73Aw+WYSnOSEkFbSC3lRlv3pfgi9yHK/eWL4B0MKV9R+PLts7N1wNH+FBULgzE
	QT1KF6U6w51Z0w3FS5rXGmbLss058jmdfKp0EI4F9ZLeIgRw1kUyfq8npNFVhb9AAWTHOkPYQ
X-Google-Smtp-Source: AGHT+IEAS26joLb+EpT9iwAQqoDB1RVa5j6MclYq/EVXgldjXmvldcrDerUeWpVb5zqXYJx7TVnqBQ==
X-Received: by 2002:a17:907:724e:b0:b04:5200:5ebe with SMTP id a640c23a62f3a-b0452006a0dmr1599058266b.54.1757093075219;
        Fri, 05 Sep 2025 10:24:35 -0700 (PDT)
Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com. [209.85.218.48])
        by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aff0971379esm1781236266b.102.2025.09.05.10.24.34
        for <io-uring@vger.kernel.org>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 05 Sep 2025 10:24:34 -0700 (PDT)
Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-b043a33b060so391405766b.1
        for <io-uring@vger.kernel.org>; Fri, 05 Sep 2025 10:24:34 -0700 (PDT)
X-Received: by 2002:a17:906:694a:b0:b04:25ae:6c76 with SMTP id
 a640c23a62f3a-b0425ae7255mr1542901366b.47.1757093073940; Fri, 05 Sep 2025
 10:24:33 -0700 (PDT)
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
In-Reply-To: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Fri, 5 Sep 2025 10:24:17 -0700
X-Gmail-Original-Message-ID: <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
X-Gm-Features: Ac12FXyoV4y7c9v5tBanggkhIakvIPB9VzULgYlJT5puVDpl0ZhN5Ti4f9cT19g
Message-ID: <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
Subject: Re: [GIT PULL] io_uring fix for 6.17-rc5
To: Jens Axboe <axboe@kernel.dk>, Caleb Sander Mateos <csander@purestorage.com>
Cc: io-uring <io-uring@vger.kernel.org>, 
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"

On Fri, 5 Sept 2025 at 04:18, Jens Axboe <axboe@kernel.dk> wrote:
>
> Just a single fix for an issue with the resource node rewrite that
> happened a few releases ago. Please pull!

I've pulled this, but the commentary is strange, and the patch makes
no sense to me, so I unpulled it again.

Yes, it changes things from kvmalloc_array() to kvcalloc(). Fine.

And yes, kvcalloc() clearly clears the resulting allocation. Also fine.

But even in the old version, it used __GFP_ZERO.

In fact, afaik the *ONLY* difference between kvcalloc() and
kvmalloc_array() array is that kvcalloc() adds the __GFP_ZERO to the
flags argument:

   #define kvcalloc_node_noprof(_n,_s,_f,_node)  \
      kvmalloc_array_node_noprof(_n,_s,(_f)|__GFP_ZERO,_node)

so afaik, this doesn't actually fix anything at all.

And dammit, this commit has that promising "Link:" argument that I
hoped would explain why this pointless commit exists, but AS ALWAYS
that link only wasted my time by pointing to the same damn information
that was already there.

I was hoping that it would point to some oops report or something that
would explain why my initial reaction was wrong.

Stop this garbage already. Stop adding pointless Link arguments that
waste people's time.

Add the link if it has *ADDITIONAL* information.

Dammit, I really hate those pointless links. I love seeing *useful*
links, but 99% of the links I actually see just point to stupid
useless garbage, and it *ONLY* wastes my time. AGAIN.

So I have not pulled this, I'm annoyed by having to even look at this,
and if you actually expect me to pull this I want a real explanation
and not a useless link.

Yes, I'm grumpy. I feel like my main job - really my only job - is to
try to make sense of pull requests, and that's why I absolutely detest
these things that are automatically added and only make my job harder.

I'm cc'ing Konstantin again, because this is a prime example of why
that automation HURTS, and he was arguing in favor of that sh*t just
last week.

Can we please stop this automated idiocy?

             Linus

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 EFBFE309EFA
	for <io-uring@vger.kernel.org>; Fri,  5 Sep 2025 17:45:52 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757094353; cv=none; b=rMdQk+7AbnJwsbFJN7eFhGDhD0w/ZE+SG9zlSyyMSNWEHcfxRPO6OE4zng3PFMIjqOUGSmSpJhHDBCExF4z8H91CKmoEI+qZp2NuTURVLcS4ePiLQbDDxS0ABSmtF50ghsK8pp+o68Nyx3VF6sUXFLRZwhcy1lnzCXd2HpMoLOE=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757094353; c=relaxed/simple;
	bh=yqW3FdRJC32oCkJ/oKS4lZ7+MZ71hnFD24XVoeXbGTc=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=ZBDCUr0GaJ5IS6/vEUmIwXm+KVtnpCGGsEsM2982pJCFElxooPBhdl0HLZ35KWa6mZ5VvdZ8vXzhes2/tsrc45MgGqeo5GPfzWObpmrNzY8jwMagbj4t4HczMM6Rt68MXRezfwAwtGfJ2WSOAoIyJCBSokj2aV/A8+hFVVJMBG4=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=kYabEX+K; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="kYabEX+K"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 80E43C4CEF1;
	Fri,  5 Sep 2025 17:45:52 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1757094352;
	bh=yqW3FdRJC32oCkJ/oKS4lZ7+MZ71hnFD24XVoeXbGTc=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=kYabEX+KYsup7xkAfUrczW0rMktG8mxD0hc9YrHp+V/BtOGIeVfaBwl9IQp/7UDA5
	 zZZ51qbh9CviWqEN0V2Sun/VDlQc/Zw69CtE6cmSVS+y7Sq9ELONxvurfB5QUIc5Rv
	 f+E4nA9QARBkOkrKQXjJLKQkFtvOK3i7V9ac6EBg=
Date: Fri, 5 Sep 2025 13:45:48 -0400
From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jens Axboe <axboe@kernel.dk>, 
	Caleb Sander Mateos <csander@purestorage.com>, io-uring <io-uring@vger.kernel.org>
Subject: Re: [GIT PULL] io_uring fix for 6.17-rc5
Message-ID: <20250905-lovely-prehistoric-goldfish-04e1c3@lemur>
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>

On Fri, Sep 05, 2025 at 10:24:17AM -0700, Linus Torvalds wrote:
> Yes, I'm grumpy. I feel like my main job - really my only job - is to
> try to make sense of pull requests, and that's why I absolutely detest
> these things that are automatically added and only make my job harder.
> 
> I'm cc'ing Konstantin again, because this is a prime example of why
> that automation HURTS, and he was arguing in favor of that sh*t just
> last week.
> 
> Can we please stop this automated idiocy?

FWIW, Link: trailers are not added by default. The maintainer has to
deliberately add the -l switch.

Do you just want this to become a no-op, or will it be better if it's used
only with the patch.msgid.link domain namespace to clearly indicate that it's
just a provenance link?

-K

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id BEBE71DED4C
	for <io-uring@vger.kernel.org>; Fri,  5 Sep 2025 18:06:20 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.54
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757095585; cv=none; b=U3MNFiANs+2916ZcGMRyoZsrSZpHDpSnBVHt3I0GmympEXbI1UiCq7ZoOHZVpYw3RdfM4k4qaodT2Y+NEGTqKmltG/Ct/s8mqaEOrgmXaaOS8NtCd+3M6lgIFSzDR51Ll6enLhY/taRFgpFb2cGGlcnxem/qEBp36x6lkW+4Gkg=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757095585; c=relaxed/simple;
	bh=OEQWGZfgcWhUNnHjg1X8TOQvGJRch28d4HeV5zhsTTI=;
	h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
	 To:Cc:Content-Type; b=NAbA8nfKR/FHJRAzqWElnLeqOV2xYm/A5xBDk8Gw6g3SA6aj4H2BPsrUvCSbcs4VO65L7d8+aVai2MuqDbne6f80CMcNKk1W89KfqWV48gKSNm5Yd0ju+IjnZwqRaeCOoLmu3NfEDBJs0bSAvvRL5Q3Diwoc78HHu9/G75SVi+g=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org; spf=pass smtp.mailfrom=linuxfoundation.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=abYHo5l4; arc=none smtp.client-ip=209.85.208.54
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linuxfoundation.org
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="abYHo5l4"
Received: by mail-ed1-f54.google.com with SMTP id 4fb4d7f45d1cf-6188b5b113eso3983107a12.0
        for <io-uring@vger.kernel.org>; Fri, 05 Sep 2025 11:06:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linux-foundation.org; s=google; t=1757095579; x=1757700379; darn=vger.kernel.org;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=Dm3iXCah8M4VwRYBc/IsYVCDyU/KPnZRsRw6XBJaJJM=;
        b=abYHo5l40mHWNc0D+QkU5PUaW1TpcVYrgdo12F3mP56g+wQs0wCKr1p/7rVzFIcLDc
         htqGPdA8NQSAM9kF69uCy+UOxiHfsjvX/gDKz7SvbPa9DOj8qKrNyCeDEvmEk5DOxt4Z
         4GFpnxeJCPgdFesm3KouXbXX6sUPRWJinvX5Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757095579; x=1757700379;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Dm3iXCah8M4VwRYBc/IsYVCDyU/KPnZRsRw6XBJaJJM=;
        b=OQ0In1hYyt9JcL9QIK9Lg6FFNpvxowGUo71Co9eIEZl9Cimw0erD4CMyaNQyV/OR2/
         q/dbIs76DP48PQVYDGOAAbTRgW814dk9d51anQOXDGk03vBDqZ7DGtmFlQ3aRg9YSzYM
         RTDcP86s56J/yqmhjww/CDxFBrcqd8OjY95rw4CUDIk+URqtjmBCiIlprSgew5lFXPOx
         16kILc3GyDoXif1a1xc663f1/aJ/bmE83F5KhxLEilatAXp6UgOfQKLymBLlSUGyJaUB
         NN7mJ+hSP2va7C7xEjxbCvy7RPqSDEl9s9vZRv6E3uQ5mLhYtlAKBRmDF11CFXYciWZ3
         h5Pw==
X-Forwarded-Encrypted: i=1; AJvYcCVbhCq4m5nIkdc5tyA95GLRsnSPLrM7nQSXAjDe/33rWsNSgqMt0c+k6HTsebS1KrWGS7vZ6TBV/g==@vger.kernel.org
X-Gm-Message-State: AOJu0YzznGmOPVYDw3frN5WZ3SjWy+URVGanp0/AoYqaQHr1xirNPtQw
	fV5iUOHXeGvh7svKQiLRvcMgGtpGLu7sInDwc5/8pVJPbAFloynEN7mn8CwofBtpDSE2Swgz+ta
	YuPYx7nM=
X-Gm-Gg: ASbGncsgRasdvR8JMFcd1bZGfd86eCi8zeI59frsIiETXFsJZvUbByeEhBQK6CMrv2c
	VqtZ8GE1ehVwdbFUFT7r24T8EmQ+kwHv4YGjFm2eUur8TJhlTrMAVIkjZnvk+Y4zQUUR2zvErjp
	3QC4/60ly2UCUo2BDz1cSFhbu6dHCAL+MJSNH1/QFNAi1t9X59BGbUoRE/laavECFzMFd0EoYHk
	If6G3InXyasUGjdiT2cDOOIGdxY1Z1VHK6xcON+vfK/lZ78QTT8O+BAvev8Ws7QpZtD5hai5hmz
	JeZ4M2dKj50obtY3ZLHyMRaLS5/mCUmKlGtBW5YbeZ7igJA7xBpRCsE+pFGdLB5VWXudXVzpwAW
	TY2r0MnxB/n4Nrp6QdEF+JYOGVxAekpuQRxqCwVP2MsGR4WkmhmQ9Fxmd3Pz/RxOcOOT2pghW
X-Google-Smtp-Source: AGHT+IEXWnU+tbblwBEmaOb0RQJ5vZ5tbSkrMzWuAypK5smCeovjp4B5+lqKDXFMUzcBzgBhEN0vCA==
X-Received: by 2002:a17:906:6a27:b0:b04:302c:fe14 with SMTP id a640c23a62f3a-b04302d0545mr1665893066b.21.1757095578673;
        Fri, 05 Sep 2025 11:06:18 -0700 (PDT)
Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com. [209.85.208.53])
        by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-62069b79e1asm3514011a12.26.2025.09.05.11.06.17
        for <io-uring@vger.kernel.org>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 05 Sep 2025 11:06:18 -0700 (PDT)
Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-622fbed96dfso572691a12.1
        for <io-uring@vger.kernel.org>; Fri, 05 Sep 2025 11:06:17 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCVtaRcIZC2xf6mtv3DQAiXEWtKjMBTaKuhng7H4zAG2JsU9s2yLNFDiPFVAppLELU/aOhNiiNwFJw==@vger.kernel.org
X-Received: by 2002:a17:907:d92:b0:b04:8435:fbe1 with SMTP id
 a640c23a62f3a-b048435fe62mr710277266b.5.1757095577504; Fri, 05 Sep 2025
 11:06:17 -0700 (PDT)
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com> <20250905-lovely-prehistoric-goldfish-04e1c3@lemur>
In-Reply-To: <20250905-lovely-prehistoric-goldfish-04e1c3@lemur>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Fri, 5 Sep 2025 11:06:01 -0700
X-Gmail-Original-Message-ID: <CAHk-=wg30HTF+zWrh7xP1yFRsRQW-ptiJ+U4+ABHpJORQw=Mug@mail.gmail.com>
X-Gm-Features: Ac12FXzmZ3xH0kS5gGF0ADZ6CaR58SY8jojpTrJcz99Wla0kP5z_gJbTB6VjxgI
Message-ID: <CAHk-=wg30HTF+zWrh7xP1yFRsRQW-ptiJ+U4+ABHpJORQw=Mug@mail.gmail.com>
Subject: Re: [GIT PULL] io_uring fix for 6.17-rc5
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: Jens Axboe <axboe@kernel.dk>, Caleb Sander Mateos <csander@purestorage.com>, 
	io-uring <io-uring@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"

On Fri, 5 Sept 2025 at 10:45, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> Do you just want this to become a no-op, or will it be better if it's used
> only with the patch.msgid.link domain namespace to clearly indicate that it's
> just a provenance link?

So I wish it at least had some way to discourage the normal mindless
use - and in a perfect world that there was some more useful model for
adding links automatically.

For example, I feel like for the cover letter of a multi-commit
series, the link to the patch series submission is potentially more
useful - and likely much less annoying - because it would go into the
merge message, not individual commits.

Because if somebody is actively looking at a merge message, they are
probably looking for some bigger picture background - or there's some
merge conflict - and at that point I expect that the initial
submission might be more relevant.

Of course, most people don't necessarily *use* the cover letter for a
merge, and only apply the patches as a series, so it's also less
annoying for the simple reason that it probably wouldn't exist in the
git history at all ;)

Anyway, the "discourage mindless use" might be as simple as a big
warning message that the link may be just adding annoying overhead.

In contrast, a "perfect" model might be to actually have some kind of
automation of "unless there was actual discussion about it".

But I feel such a model might be much too complicated, unless somebody
*wants* to explore using AI because their job description says "Look
for actual useful AI uses". In today's tech world, I assume such job
descriptions do exist. Sigh.

For example, since 'b4' ends up looking through the downstream thread
of a patch anyway in order to add acked-by lines etc, I do think that
in theory there could be some "there was lively discussion about this
particular patch, so a link is actually worth it" heuristic.

In theory.

And honestly, even if the discussion ends up being worthless, I do
suspect I would be a lot *less* annoyed by a link that at least leads
to some _thread_ (and not just the acked-by emails that already got
gathered up), rather than just leading to an email that was applied
and nobody really had any input on.

At least at that point I'd feel like there's something real there.

And yes, as always, I realize that people think that patch submissions
will get more email replies at some hypothetical _later_ date.  But in
practice, that seldom happens, because the downstream testing issues
typically create new threads, not replies to original emails (and if
they *do* react to the original email, we already can look up the
commit easily, and the lookup goes the other way anyway).

           Linus

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com [209.85.219.177])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id E5348315D22
	for <io-uring@vger.kernel.org>; Fri,  5 Sep 2025 19:04:30 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.177
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757099074; cv=none; b=rqoBjDiFXt+kYcNQSS1cq+cqbSJf/t+akNGT+6nTPg6HsJfCK3OBGkveH1p8QCAWtP+d9PxA3rFp/d3ZSrXyRukIzeJr0Fb9FNStSHyW/22Wr2A2fIB5oouJDa6NjbB2CSHPG0qWO47lpiS+EqeYmu0nZCbCz+wVkuMgVm5dWhQ=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757099074; c=relaxed/simple;
	bh=Sn0BXbM07idm8sO438PzPmjUPqXnWU0r7K0IwlqvU2Q=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=VcOMJABExx/IbwymUNriykf3rHy4F9cLTsQPg1jhCG/1O6d1LvVHWbyae8i7iY5TL7Hwi1ToNcLiJAp6RgFLBDQZ5pnPSFIYkFV1L/jhHcpIRtyGx4dHmdfZ05bt8SKSV/1Rh/3nSAok8hZkdV6B6x4ngAwwamVPr2HM7cJnWh8=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk; spf=pass smtp.mailfrom=kernel.dk; dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b=xzWjbI+J; arc=none smtp.client-ip=209.85.219.177
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kernel.dk
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b="xzWjbI+J"
Received: by mail-yb1-f177.google.com with SMTP id 3f1490d57ef6-e96e45e47daso2038334276.3
        for <io-uring@vger.kernel.org>; Fri, 05 Sep 2025 12:04:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=kernel-dk.20230601.gappssmtp.com; s=20230601; t=1757099070; x=1757703870; darn=vger.kernel.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=XxBCZX8Izl5D+0pOg4L/p29Smjh1ZAemLQvdEG9SfkY=;
        b=xzWjbI+Jazwey4gXQB2ioa/r+aiy5on3kLlycKfd3K6G9U6OgsQHSLp+59QF1qISCw
         /tXZltM+2Sbi+49duXNJCZMm1ReOfGBbNKPxIElvmbuSWhUAhqtRrNWKFl/WMNsyJ3Wg
         nbyUdtgF8wanxYx02cUMJG2WtNk2AfdaMFsMSGhcpZjBl20WEAnb+XqlonMH67+bZvtT
         mL1Sui9I4Et8T3GaMtlrPEGO3CzFIkYzjMncCv2XlHZ0ve+KGp5l6JNuxx/QYvgO4fKV
         MBXQ0k15o4JWycn04MHBvoxo3sjFvYs18SWOyGYXUh9PWg9GDk3u2wLQbQAxOKmIaVuf
         oN+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757099070; x=1757703870;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=XxBCZX8Izl5D+0pOg4L/p29Smjh1ZAemLQvdEG9SfkY=;
        b=alxKfjmIVmDwQeO3wuh/R7+X1a0yy8WW73Qifz9ddf6Ys1xsZl1Rt82qXO8VPNZji6
         RwsV1cQPx738tQGGLTjer+jlyqt/nIUKbpy5CJ4Uru09X1w6kS/l+7U7tWbK3ilhoRHO
         2olfwjGcyzgxXcpowENmWebtZ/EYu7XnvoJFhZgzSFf8LzgpH+d8XV/FBq6S3xo/Bbn+
         fLV1Q7XvB0OrZSw6tXMuTl3TU+vFdjYIvxr2IZKZrUiCt9cm/mYxg/y+AucNv6dvU2Ns
         h2h0EWXCQYQBTwiw9rkr9PiQdcJqR1uInBbymtaO56NGRR7YCK8p6lZSjiC6jqQBKm/h
         Z0KA==
X-Gm-Message-State: AOJu0YzZkRZI5yxucmpYocFgDHA0/nCn8SvebBIQYKaTCVDX40f7WxKf
	B0Vy3iOPvzKIe5/c426GxIFbpXum0yv0qRUBojx6mC3kbeOInTTJ5A9dUjhjphRpwzk=
X-Gm-Gg: ASbGncvmI4BdStMDd44YZvUcWHCs5f+X0vyXXDIjbTXZZipTo7qYyF+JbNDNQSXyAYV
	6uFc2A8SiqHYeL1MXnSQSf3iFWgMWAN60RVVNby2qhX1HjlYMm8B+UmMVi3M9FzJ5oCb5hEuQoO
	b6+zF4yEG8xz4rV8rrehAD1Y2Mi0WRMPLVlP5LSG0+gZqaVLirX7hMaSKgFJMuHdp8h+1gaE3Cc
	PEuPETJKZNvu8JzCViiY64+9ERicjbS0PnTTCodBLmtyhR1QdcMoMXvb1n9jdZ638ACCNPAeLFb
	JDKo7ZFcYmlHF/XWJIw4yHZxpp4hKJvfAZ1eScALYx4sZ4wLzT3BFBF9iuP804cj8Kb46xVAqLV
	jK3DsKkQdTqC++nfMbF3deglQknBe1w==
X-Google-Smtp-Source: AGHT+IGzubTeOJn31WfH2BTfn46wcrLD+ISMCUoNPouJZ3zCsopnZCIZIAUP7TuFPBZvEWtUnf6ETQ==
X-Received: by 2002:a05:690c:ec8:b0:71f:cefd:dd39 with SMTP id 00721157ae682-722765755a5mr242989747b3.50.1757099069614;
        Fri, 05 Sep 2025 12:04:29 -0700 (PDT)
Received: from [172.17.0.109] ([50.168.186.2])
        by smtp.gmail.com with ESMTPSA id 00721157ae682-723a85aefcfsm31234077b3.68.2025.09.05.12.04.28
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 05 Sep 2025 12:04:29 -0700 (PDT)
Message-ID: <f0f31943-cfed-463d-8e03-9855ba027830@kernel.dk>
Date: Fri, 5 Sep 2025 13:04:28 -0600
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [GIT PULL] io_uring fix for 6.17-rc5
To: Linus Torvalds <torvalds@linux-foundation.org>,
 Caleb Sander Mateos <csander@purestorage.com>
Cc: io-uring <io-uring@vger.kernel.org>,
 Konstantin Ryabitsev <konstantin@linuxfoundation.org>
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
Content-Language: en-US
From: Jens Axboe <axboe@kernel.dk>
In-Reply-To: <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 9/5/25 11:24 AM, Linus Torvalds wrote:
> On Fri, 5 Sept 2025 at 04:18, Jens Axboe <axboe@kernel.dk> wrote:
>>
>> Just a single fix for an issue with the resource node rewrite that
>> happened a few releases ago. Please pull!
> 
> I've pulled this, but the commentary is strange, and the patch makes
> no sense to me, so I unpulled it again.
> 
> Yes, it changes things from kvmalloc_array() to kvcalloc(). Fine.
> 
> And yes, kvcalloc() clearly clears the resulting allocation. Also fine.
> 
> But even in the old version, it used __GFP_ZERO.
> 
> In fact, afaik the *ONLY* difference between kvcalloc() and
> kvmalloc_array() array is that kvcalloc() adds the __GFP_ZERO to the
> flags argument:
> 
>    #define kvcalloc_node_noprof(_n,_s,_f,_node)  \
>       kvmalloc_array_node_noprof(_n,_s,(_f)|__GFP_ZERO,_node)
> 
> so afaik, this doesn't actually fix anything at all.

Agree, I think I was too hasty in queueing that up. I overlooked that we
already had __GFP_ZERO in there. On the road this week and tending to
these kinds of duties in between, my bad. Caleb??

> And dammit, this commit has that promising "Link:" argument that I
> hoped would explain why this pointless commit exists, but AS ALWAYS
> that link only wasted my time by pointing to the same damn information
> that was already there.

[snip long rant on Link: tags]

I just always add these, because discussion might happen after the fact.
For example, someone might run into an issue from an added patch, and
reply to the list. That does happen.

IMHO it's better to have a Link and it _potentially_ being useful than
not to have it and then need to search around for it. Searching is MUCH
worse than the disappointment of a Link that tells you nothing that
isn't in the commit already, and it wastes a lot more time.

And if you're applying a series of patches, then it'll take you to the
cover letter. Which is useful. All without needing to go search on lore.
You could argue that you could turn any applied series into a merge and
add the cover letter there, or link it at least, but lots of things
don't end up in a merge commit before you pull it.

What is the hurt here, really, other than you being disappointed there's
nothing extra in the link?

I, and everybody else, can surely start making judgement calls on when
to add the Link or not. But that seems error prone, and might indeed
miss useful cases because a bug report comes in AFTER the fact.

In any case, if it really bothers you that much, then just make it
policy. Historically I suppose policy has very much been formed by Linus
rants in replies, which then gets picked up by LWN and others and then
it becomes part of "Linux kernel lore" of this is what Linus expects.
But I bet you that LWN would pick up a Linus email on the topic that
isn't a reply, which said that you've observed Link: tag being used
frivilously and why you find that annoying. And THAT would save you a
lot more time rather than need to rant about it multiple times.

-- 
Jens Axboe

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id B0AC22798E3
	for <io-uring@vger.kernel.org>; Fri,  5 Sep 2025 19:07:28 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.181
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757099251; cv=none; b=XJhg+/QfEusKncgEU8y2xe+s2Y9h9N7rE+YAeXX+iV1WfQdN3AM8S/NlEC97hDwRVDNJ6YokngUtbKhXw8qcJalQpq8klW5/lur2E9CPRzEVt1OBc5AZyVKgsXD0X64tFPw+8kzz3CPH6JZKor/oQCYAS4S4Djds75H/8yqmH60=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757099251; c=relaxed/simple;
	bh=vlr48yjk2puCT7uOaqK3TIiyqr5+WEUX/j47wSb86CU=;
	h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References:
	 In-Reply-To:Content-Type; b=H+sw4rpFhce1YFLqchzpV1wAx22A8NineXuCM2Bv5ZScbw8/rndawOwDIkAAXTS9lhAjKd49tREYSS5qxfHhtePSdKzXZ+F43gtDwXW7JHaUUhQVMF/vBeeXCzL3cmHk4qcYKFqm1TA6vvhrRGmwYc08Fow7FLmZplunIrNoNcw=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk; spf=pass smtp.mailfrom=kernel.dk; dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b=GmAZhFgj; arc=none smtp.client-ip=209.85.219.181
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kernel.dk
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b="GmAZhFgj"
Received: by mail-yb1-f181.google.com with SMTP id 3f1490d57ef6-e98a18faa25so2334384276.2
        for <io-uring@vger.kernel.org>; Fri, 05 Sep 2025 12:07:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=kernel-dk.20230601.gappssmtp.com; s=20230601; t=1757099248; x=1757704048; darn=vger.kernel.org;
        h=content-transfer-encoding:in-reply-to:content-language:references
         :cc:to:from:subject:user-agent:mime-version:date:message-id:from:to
         :cc:subject:date:message-id:reply-to;
        bh=/uT4lkvGe+y46mKowMKKO7TyZfguuQ/FdpoqEpw5I3k=;
        b=GmAZhFgjy5OW8WRnWZ/duLDmuFrzQ3fCaOd/zBrz08Hce5w3tSmN1ZptomdpoOtCpp
         PWxp33baQ3CafLwKA7xF7L7iXCzn9I3MWdtFxaLZ8MzBxiCa4SoYCx7ghgJ8T/ndZIa6
         p4d+W8HfiWNRu0WQAOe77Ca+RWHKGAOE4M8Rp0x5HaT8Y39eEg/WX5cEbyln1uP0V9v0
         G7c1+wKIEPQHBTKIf+XciLfYGxaQdeyNOTnnumtKi4yoZHQPwfEhaxUVbbTOkG05pQdC
         dHmuJdZd49zU411tMMyuXyzepLzKvacV0eKislt1TrMQWFa6VWyo/g46t2HUdphIhEsZ
         jEMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757099248; x=1757704048;
        h=content-transfer-encoding:in-reply-to:content-language:references
         :cc:to:from:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=/uT4lkvGe+y46mKowMKKO7TyZfguuQ/FdpoqEpw5I3k=;
        b=Btj3/API9g2WM7UdngwNJbRaH37JYUdNJ1whisI9IO7Bp6vbkyrldN76F9tvDfpV+p
         QrD7eDwZGOcBojS52nj3ODdmCA7X62cVKTct5cWgjoqmuh+QHDd1GYwSbUpHo0J0FOnI
         tfyeSDQzTUSQdtDXNyJxuVaI8gdS4hsUlDfBcC6+EFh/MhFgBqwAvYy93ZyhHDRuhnta
         CcofJjpplbzIWREYBpx/7OPD3KMk2aeD6tHUw83tcvDPSbBzRadNDFVZ3DkhQQ/PvIsd
         ssQiCnXXrVIdWN4wsaGtO69UPSgVDLFVBRScGe3Z5Xp+iDA5Mrx96BoZYtACNA/wKKnc
         KJaw==
X-Gm-Message-State: AOJu0Yxvg/+Ep7QZeUlytj27BwdSBZYB2VZ/FfIZXRABA3W6wOl0iPIL
	Qc6VpCqeffa9gl4rwcjabeC5BiW+9NpShTPAoQgYjPYha/DzwHnSqS4FQ2PH6ynrPvs=
X-Gm-Gg: ASbGnctdn+mfIiXcCES9glhX/lTsjXdM1iy7+3ZBf+fiXnifHVH6aGHoz++BSNWRAVs
	2+yUM6HoUnUo7Lh9oP42YTq1DQUa9tGb2KVy5T5zCIBf3dW5cCLz8cg1/8NbeusT7NyvoK1YdZX
	GjPwqDCAAplFsY/GbuKnkUerZ+paBQBwW8KHSIPAslf8ToLr8QjkcfKEzYK0a8BUkTCvvNdWSxs
	ri0RFyqXvdLgdDJNIHkWoc9ZvFdpqmXmUeRRAYl3jImJ6+M29gA5DFlw+EUigJjBflk7/aXLSCQ
	5s45vdmWnoWjX6eIOARnHvB34dnBb56eqd41nHbnQm/L6naLeZdVV3TzyhPaeolbPDwNRK1a5Hw
	LsRgUOV8eeiQq4+/EVlU=
X-Google-Smtp-Source: AGHT+IHRaFtjoK5bo9szmroiEQrbnORGl1E5zP1Dql8mRsC2FHxr2c2Me/4PQx9Sja95+qCmVuLMHw==
X-Received: by 2002:a05:6902:4a82:b0:e97:d52:c5d0 with SMTP id 3f1490d57ef6-e98a575c25dmr21468168276.2.1757099247507;
        Fri, 05 Sep 2025 12:07:27 -0700 (PDT)
Received: from [172.17.0.109] ([50.168.186.2])
        by smtp.gmail.com with ESMTPSA id 3f1490d57ef6-e9bbe19ae4asm3353020276.32.2025.09.05.12.07.26
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 05 Sep 2025 12:07:26 -0700 (PDT)
Message-ID: <67393fa5-d103-48a0-b62b-0f9197bfdc99@kernel.dk>
Date: Fri, 5 Sep 2025 13:07:26 -0600
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [GIT PULL] io_uring fix for 6.17-rc5
From: Jens Axboe <axboe@kernel.dk>
To: Linus Torvalds <torvalds@linux-foundation.org>,
 Caleb Sander Mateos <csander@purestorage.com>
Cc: io-uring <io-uring@vger.kernel.org>,
 Konstantin Ryabitsev <konstantin@linuxfoundation.org>
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
 <f0f31943-cfed-463d-8e03-9855ba027830@kernel.dk>
Content-Language: en-US
In-Reply-To: <f0f31943-cfed-463d-8e03-9855ba027830@kernel.dk>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 9/5/25 1:04 PM, Jens Axboe wrote:
> On 9/5/25 11:24 AM, Linus Torvalds wrote:
>> On Fri, 5 Sept 2025 at 04:18, Jens Axboe <axboe@kernel.dk> wrote:
>>>
>>> Just a single fix for an issue with the resource node rewrite that
>>> happened a few releases ago. Please pull!
>>
>> I've pulled this, but the commentary is strange, and the patch makes
>> no sense to me, so I unpulled it again.
>>
>> Yes, it changes things from kvmalloc_array() to kvcalloc(). Fine.
>>
>> And yes, kvcalloc() clearly clears the resulting allocation. Also fine.
>>
>> But even in the old version, it used __GFP_ZERO.
>>
>> In fact, afaik the *ONLY* difference between kvcalloc() and
>> kvmalloc_array() array is that kvcalloc() adds the __GFP_ZERO to the
>> flags argument:
>>
>>    #define kvcalloc_node_noprof(_n,_s,_f,_node)  \
>>       kvmalloc_array_node_noprof(_n,_s,(_f)|__GFP_ZERO,_node)
>>
>> so afaik, this doesn't actually fix anything at all.
> 
> Agree, I think I was too hasty in queueing that up. I overlooked that we
> already had __GFP_ZERO in there. On the road this week and tending to
> these kinds of duties in between, my bad. Caleb??
> 
>> And dammit, this commit has that promising "Link:" argument that I
>> hoped would explain why this pointless commit exists, but AS ALWAYS
>> that link only wasted my time by pointing to the same damn information
>> that was already there.
> 
> [snip long rant on Link: tags]
> 
> I just always add these, because discussion might happen after the fact.
> For example, someone might run into an issue from an added patch, and
> reply to the list. That does happen.
> 
> IMHO it's better to have a Link and it _potentially_ being useful than
> not to have it and then need to search around for it. Searching is MUCH
> worse than the disappointment of a Link that tells you nothing that
> isn't in the commit already, and it wastes a lot more time.
> 
> And if you're applying a series of patches, then it'll take you to the
> cover letter. Which is useful. All without needing to go search on lore.
> You could argue that you could turn any applied series into a merge and
> add the cover letter there, or link it at least, but lots of things
> don't end up in a merge commit before you pull it.
> 
> What is the hurt here, really, other than you being disappointed there's
> nothing extra in the link?
> 
> I, and everybody else, can surely start making judgement calls on when
> to add the Link or not. But that seems error prone, and might indeed
> miss useful cases because a bug report comes in AFTER the fact.
> 
> In any case, if it really bothers you that much, then just make it
> policy. Historically I suppose policy has very much been formed by Linus
> rants in replies, which then gets picked up by LWN and others and then
> it becomes part of "Linux kernel lore" of this is what Linus expects.
> But I bet you that LWN would pick up a Linus email on the topic that
> isn't a reply, which said that you've observed Link: tag being used
> frivilously and why you find that annoying. And THAT would save you a
> lot more time rather than need to rant about it multiple times.

Oh, and I totally forgot the relevant tag this time:

Link: https://media.tenor.com/74lPb8mSRQMAAAAM/abe-simpson-abe-simpson-cloud.gif

;-)

-- 
Jens Axboe


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com [209.85.210.177])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 737AC315D2E
	for <io-uring@vger.kernel.org>; Fri,  5 Sep 2025 19:14:01 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.177
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757099643; cv=none; b=kPVtn/8/YFP3RL/pH8VIQWAFSCmBw3oqw4GC8Bmhg4UZbAzd57/hmay9TDkN5wMiRNRpM2p6bML8nVCJhIap6T6izpuJNoyViZgbnYraB7l3Fn2M+sZl+G2nj55BwNQNCjrDTVHJZfmAVFHNbCX/ERavOfFCaMp5GeVmhI++KjM=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757099643; c=relaxed/simple;
	bh=ogRuMQFeAGOymg8wQrX8REfn0ikj+Fj0MUpDTeWOh+Q=;
	h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
	 To:Cc:Content-Type; b=kk4DgIzjdHXiEccje0qsiY8jiHupUXTen23tG6CEcFx8H3aKRGYOa5YAt+ZvGxf//QCGXmlVP9MpcZcmyy0zsXvS4g6Hl9cCzR+Gat+KfnfTOUIryLdDKtjVS/TEVR5gfl+gaN5hjJDgO7fvhzQ7EYVKzEYjxdDNPijtqu9VZEw=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=purestorage.com; spf=fail smtp.mailfrom=purestorage.com; dkim=pass (2048-bit key) header.d=purestorage.com header.i=@purestorage.com header.b=IeAv/sL4; arc=none smtp.client-ip=209.85.210.177
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=purestorage.com
Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=purestorage.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=purestorage.com header.i=@purestorage.com header.b="IeAv/sL4"
Received: by mail-pf1-f177.google.com with SMTP id d2e1a72fcca58-772759a7dfbso231647b3a.3
        for <io-uring@vger.kernel.org>; Fri, 05 Sep 2025 12:14:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=purestorage.com; s=google2022; t=1757099641; x=1757704441; darn=vger.kernel.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=fX9Q1Z82rqELs3VftvCK7vHHBqL7+0LiZF2iKflj/qU=;
        b=IeAv/sL4+FEvDjvCgGqbdUbGM4UNWBUwK5BfhHt7Pl58cBSSvhPC2LVvWc4S0SpDKn
         uF+qxsPSBKmJV/mowvc8H3XA6Ukw07//CM71ss65JfvFDviK/gYoupXJ+UVaMRyHCIWt
         nVnQ7Z5xYzODRIlp2HQuss8iwi7Y+d6pK3V+8j1Mponl3K1qbpZDyyzYGXZxEcja+RNW
         mC3E0QCUCnAP2Pc3QxV/Q1pstVlKSwM/SmsXFMc8rwZunwkjaCSCD+dOTwNYvSKsgB1D
         N/cLS4pdwSXtrZda3WqftIYgoDgSogAggItqGBUieEYNmTn+fOn5Bs7b3SYugTaR8FOc
         s5Sw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757099641; x=1757704441;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=fX9Q1Z82rqELs3VftvCK7vHHBqL7+0LiZF2iKflj/qU=;
        b=ioBGn+mpX+qzjT8kSaRjEVVzBPyZzbyDB7D9DLupEmwQRWEjg77RUn70ktEM7NdTB7
         RyODvp1xViGUE1LrJUTXLSf1/EP26H8dHHA9k7bWdNAN6cCyiXNmpe9JCkrTmN5sqwRk
         BmQfWT1AgHUZQh7G/+c6nthh+8Esx0avNbUxdyb0IV1C8dUgzZrKW5pgS4x7HKLfN2G0
         jeXHbH1571Rk4iSsaHzOwG/8e8KiZvlJfIM0H9/uGAWl8xJNxa49ai12eZZRQNolcvSn
         QJmXURHhdRyqPwQJoYhM4EzJJ9EhFoZ+EJPiL58fzcQEhQJFaN0nFDwqKgplv16ah0ur
         k4dQ==
X-Forwarded-Encrypted: i=1; AJvYcCVHIJYbD1nEYSUa4IYDdAM4QIy5teBkyc38/5zGJDLmh0ktAPWL3X9xWlj4KJ7CtKxcmAPgoLAyOw==@vger.kernel.org
X-Gm-Message-State: AOJu0YxpWrkRBDaeSLLsL+H0gA1ZwMOd0kIlsh77nZAOIcoYa7TSu6Nh
	Tbx3U1ittorH71Yn2cU9S1xHj/2FtfhEqpVQt+CfJXfUUke/Vnf1OHImrhs6O1Zl8NJJvL+/kFr
	5xEyoPuTxvJLIDIkaNxo+SQgI3atCrYjDZcbSk9V1Sw==
X-Gm-Gg: ASbGncshv8NQyNrg+Bm/0wwGDk3MCUCzp9gSbS6vDSecs7ZSjIVmZ5joHC8Vh3+ObPq
	A3itas+x9F2oRYnF+fA7g19I7luhuzPds0wG3LKDBb+pWSQmAWrk7oi1PWN5ShzeaTilHBqBOJM
	EcRIC4hXuGmFJmfKGyzkmVfW+vkheFUaVDyraA8QYo7lMNxnHCaKCQIyoLO6oGNlJAel/m3jxqg
	AQs5XtF3NBe9N+k2ufBzC0=
X-Google-Smtp-Source: AGHT+IEE8PufdF6KPU2wS1JXaMJ8NvTMJ0aXU61DIrasRN8b4fzlkUHR1cqvp0DPHwSxoz0q3HbmuL/CFtGR2b9loy8=
X-Received: by 2002:a17:90b:2250:b0:32b:aed4:aa1a with SMTP id
 98e67ed59e1d1-32baed4ade9mr3970756a91.4.1757099640579; Fri, 05 Sep 2025
 12:14:00 -0700 (PDT)
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com> <f0f31943-cfed-463d-8e03-9855ba027830@kernel.dk>
In-Reply-To: <f0f31943-cfed-463d-8e03-9855ba027830@kernel.dk>
From: Caleb Sander Mateos <csander@purestorage.com>
Date: Fri, 5 Sep 2025 12:13:48 -0700
X-Gm-Features: Ac12FXyQVbvCNly74ch1I2GsEZiW4vUkm2Ern8Oy5ByKcadZy4GawEnB--JoHHU
Message-ID: <CADUfDZr+pvC5o-y2f1WqwyxButkTN2Lesu0Ya5qrg2nVXVF9pQ@mail.gmail.com>
Subject: Re: [GIT PULL] io_uring fix for 6.17-rc5
To: Jens Axboe <axboe@kernel.dk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>, io-uring <io-uring@vger.kernel.org>, 
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 5, 2025 at 12:04=E2=80=AFPM Jens Axboe <axboe@kernel.dk> wrote:
>
> On 9/5/25 11:24 AM, Linus Torvalds wrote:
> > On Fri, 5 Sept 2025 at 04:18, Jens Axboe <axboe@kernel.dk> wrote:
> >>
> >> Just a single fix for an issue with the resource node rewrite that
> >> happened a few releases ago. Please pull!
> >
> > I've pulled this, but the commentary is strange, and the patch makes
> > no sense to me, so I unpulled it again.
> >
> > Yes, it changes things from kvmalloc_array() to kvcalloc(). Fine.
> >
> > And yes, kvcalloc() clearly clears the resulting allocation. Also fine.
> >
> > But even in the old version, it used __GFP_ZERO.
> >
> > In fact, afaik the *ONLY* difference between kvcalloc() and
> > kvmalloc_array() array is that kvcalloc() adds the __GFP_ZERO to the
> > flags argument:
> >
> >    #define kvcalloc_node_noprof(_n,_s,_f,_node)  \
> >       kvmalloc_array_node_noprof(_n,_s,(_f)|__GFP_ZERO,_node)
> >
> > so afaik, this doesn't actually fix anything at all.
>
> Agree, I think I was too hasty in queueing that up. I overlooked that we
> already had __GFP_ZERO in there. On the road this week and tending to
> these kinds of duties in between, my bad. Caleb??

Sorry, this is my fault. I misread the code, the __GFP_ZERO does
ensure the correct behavior. kvcalloc() might more clearly indicate
the intent, but there's no bug. Apologies for the hasty patch, and
agree it can be dropped.

Best,
Caleb


>
> > And dammit, this commit has that promising "Link:" argument that I
> > hoped would explain why this pointless commit exists, but AS ALWAYS
> > that link only wasted my time by pointing to the same damn information
> > that was already there.
>
> [snip long rant on Link: tags]
>
> I just always add these, because discussion might happen after the fact.
> For example, someone might run into an issue from an added patch, and
> reply to the list. That does happen.
>
> IMHO it's better to have a Link and it _potentially_ being useful than
> not to have it and then need to search around for it. Searching is MUCH
> worse than the disappointment of a Link that tells you nothing that
> isn't in the commit already, and it wastes a lot more time.
>
> And if you're applying a series of patches, then it'll take you to the
> cover letter. Which is useful. All without needing to go search on lore.
> You could argue that you could turn any applied series into a merge and
> add the cover letter there, or link it at least, but lots of things
> don't end up in a merge commit before you pull it.
>
> What is the hurt here, really, other than you being disappointed there's
> nothing extra in the link?
>
> I, and everybody else, can surely start making judgement calls on when
> to add the Link or not. But that seems error prone, and might indeed
> miss useful cases because a bug report comes in AFTER the fact.
>
> In any case, if it really bothers you that much, then just make it
> policy. Historically I suppose policy has very much been formed by Linus
> rants in replies, which then gets picked up by LWN and others and then
> it becomes part of "Linux kernel lore" of this is what Linus expects.
> But I bet you that LWN would pick up a Linus email on the topic that
> isn't a reply, which said that you've observed Link: tag being used
> frivilously and why you find that annoying. And THAT would save you a
> lot more time rather than need to rant about it multiple times.
>
> --
> Jens Axboe

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-yw1-f169.google.com (mail-yw1-f169.google.com [209.85.128.169])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 93857225A29
	for <io-uring@vger.kernel.org>; Fri,  5 Sep 2025 19:16:23 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.169
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757099786; cv=none; b=tspEVQeLjC6DoBL8CrByFbFEjZvOfWVstzmsUljjFXt8IMAx87wD2MCa4HlCKrEt/JjZPJtHx8cl5ixN5rmSqwa4yBtQQ++k0oHOpBGe/Hb5uY5eqO+tuL9QkOzqoSymowgtnBlZm/z/EFBSqh9NDs9gSVP/ZRuopKObd4pWNDY=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757099786; c=relaxed/simple;
	bh=l+eIAbchEH1foTT9oClPfD2ccD3oLKevpTByElW1z4k=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=QS4a+IE0raCSYlmWHJjP2EMTkVKfNd4M8BDW5biTIV+uTOMkqI39IdAq1DpgbLeKG83tI53UZZtGf6elXUHG2TUbUFg+tpVpS6IsGYu+rGlKmLx2ssc7AmSqqBW0OoeC1EDNaiTcZ6kmXvqFGg0uRb9VRnVFqAO3kHyHuvcQCD4=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk; spf=pass smtp.mailfrom=kernel.dk; dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b=cdFQwwZi; arc=none smtp.client-ip=209.85.128.169
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kernel.dk
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b="cdFQwwZi"
Received: by mail-yw1-f169.google.com with SMTP id 00721157ae682-723960ded6bso26792037b3.3
        for <io-uring@vger.kernel.org>; Fri, 05 Sep 2025 12:16:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=kernel-dk.20230601.gappssmtp.com; s=20230601; t=1757099782; x=1757704582; darn=vger.kernel.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=2FvVjSd+gjkzhI4BuKsqLq/aKkbLRey2znFDsvr54js=;
        b=cdFQwwZiI5f3LAUYlwgBHc13lafN1V99udRO4iABnKSA/VI7+oRLUqmbzD0Grh+2E0
         Ka9ry8jQZEJGoQmN/bAVqX0c3iQoo7e1y6wdoEYCWGY7o4hfSB5JB5ZxGavJAMfpuj95
         Kj66Yf5inf2RJGdr9mk9C6EPSScYsXk6efXyMoPGf7Ebq7mrfDrBV7oDv0uEn6tpfp8S
         n7dqLXcDKEm1ESmRqAbEAWwwK3gmxoZu2eYLFnmoKgaVuDRW6Xw6WGs1/nXg4z1GxlP7
         xsyuO+0kEzKng10N5AnQ28CSXGV8Y3yvxL4c0XzvwhYQEDMDyEqTgKhGJIpJrDSHdsPY
         nPzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757099782; x=1757704582;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=2FvVjSd+gjkzhI4BuKsqLq/aKkbLRey2znFDsvr54js=;
        b=XGSUW2qPMtAE7Hz6Dl7BKxSbltVWuQ94Mb+YcHudlh68FF2IY0J27B5vsXOmuBaLTl
         YydPzKzBNbllKL+EEvvh6+RtWx7n9pEwlEpcwFkFegDHUgvmRW1LSBWD7On42tt0qBnB
         bYTDHj0XunzRCG0rwrI5xqjXLsN24ByuJTG7QDDpIZZId1Ry1HZx+E94J3C30ajSk4B6
         /5LlOfVcn6chL8Z8+NMq8bGSG2zqUe1vHq03RYkPkF+1xrUMFUp9OZ3a8gG7Hx0J0qxv
         6PS83O97gvsY4CxoTZUkjWU9/T4F0DVIX1cAOjrFonUixyCEgd1sL+VVdIEcxpQ29IKx
         97mQ==
X-Forwarded-Encrypted: i=1; AJvYcCW3CZbvF23H/L2khg3rRBtXba7SgjnjYPWXKuC6VqSCJ+smBEIPQDmiq4YU48LLZ/bG2/E3UXSV8g==@vger.kernel.org
X-Gm-Message-State: AOJu0YyKg8asYyou9snqLHYjWEWXQU+O3BFefXbGDcjPqap86Qm0AtVC
	MQMd7IxHqR2ldn6XKAVefTT4TlHsVeckMaFeFivy8R/ayv8IBcyJuBQOa+PYQOq16Ps=
X-Gm-Gg: ASbGncvWlP5WyuELSs/pb92LymP8PspJjSQVbUvzBoxn3WF3icpdPJWic+rP2IG7FX6
	SVaEm4vor30i/MY7nVcGN6w0JhjL5RxGszCMEztvJinW0UBimgOLD3lgz+5PETPPUKBe+71xmjt
	ubt2Hjsvt9C2dhwDC65MxVxmP+kunemUbI/qEIh96VbHPHq8qnigFV23haGVnd8X+sAdVKIuowN
	zZ3SMohm7pp2SmiWXSkPftyT+MyYwK9RL4Iqkv8GmCqiweVND9YWc7MbjlqPQga/OZuAykIb1iK
	YQNLSB3We1jYHmGdZAQJJ6muxo78wk49SAqvSVcvVAglE8Fk68JkdN0Gy/n1xPdZQb3lpJsSFGx
	0ykIIuwsiDEx0JevXg6s=
X-Google-Smtp-Source: AGHT+IEzAVa+gSgSYDoekwHWXknUw2QfU7BZlk9cGb03baNQFJ4Pu294FqXRa4sPu51wBXkpLOy49w==
X-Received: by 2002:a05:690c:30a:b0:71f:a867:3fa8 with SMTP id 00721157ae682-727f3686507mr54967b3.20.1757099782229;
        Fri, 05 Sep 2025 12:16:22 -0700 (PDT)
Received: from [172.17.0.109] ([50.168.186.2])
        by smtp.gmail.com with ESMTPSA id 956f58d0204a3-5ff8555d262sm2742927d50.2.2025.09.05.12.16.21
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 05 Sep 2025 12:16:21 -0700 (PDT)
Message-ID: <18e33aa8-34a8-428e-bff0-ec6839a5028a@kernel.dk>
Date: Fri, 5 Sep 2025 13:16:21 -0600
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [GIT PULL] io_uring fix for 6.17-rc5
To: Caleb Sander Mateos <csander@purestorage.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
 io-uring <io-uring@vger.kernel.org>,
 Konstantin Ryabitsev <konstantin@linuxfoundation.org>
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
 <f0f31943-cfed-463d-8e03-9855ba027830@kernel.dk>
 <CADUfDZr+pvC5o-y2f1WqwyxButkTN2Lesu0Ya5qrg2nVXVF9pQ@mail.gmail.com>
Content-Language: en-US
From: Jens Axboe <axboe@kernel.dk>
In-Reply-To: <CADUfDZr+pvC5o-y2f1WqwyxButkTN2Lesu0Ya5qrg2nVXVF9pQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 9/5/25 1:13 PM, Caleb Sander Mateos wrote:
> On Fri, Sep 5, 2025 at 12:04?PM Jens Axboe <axboe@kernel.dk> wrote:
>>
>> On 9/5/25 11:24 AM, Linus Torvalds wrote:
>>> On Fri, 5 Sept 2025 at 04:18, Jens Axboe <axboe@kernel.dk> wrote:
>>>>
>>>> Just a single fix for an issue with the resource node rewrite that
>>>> happened a few releases ago. Please pull!
>>>
>>> I've pulled this, but the commentary is strange, and the patch makes
>>> no sense to me, so I unpulled it again.
>>>
>>> Yes, it changes things from kvmalloc_array() to kvcalloc(). Fine.
>>>
>>> And yes, kvcalloc() clearly clears the resulting allocation. Also fine.
>>>
>>> But even in the old version, it used __GFP_ZERO.
>>>
>>> In fact, afaik the *ONLY* difference between kvcalloc() and
>>> kvmalloc_array() array is that kvcalloc() adds the __GFP_ZERO to the
>>> flags argument:
>>>
>>>    #define kvcalloc_node_noprof(_n,_s,_f,_node)  \
>>>       kvmalloc_array_node_noprof(_n,_s,(_f)|__GFP_ZERO,_node)
>>>
>>> so afaik, this doesn't actually fix anything at all.
>>
>> Agree, I think I was too hasty in queueing that up. I overlooked that we
>> already had __GFP_ZERO in there. On the road this week and tending to
>> these kinds of duties in between, my bad. Caleb??
> 
> Sorry, this is my fault. I misread the code, the __GFP_ZERO does
> ensure the correct behavior. kvcalloc() might more clearly indicate
> the intent, but there's no bug. Apologies for the hasty patch, and
> agree it can be dropped.

The fact that there isn't a bug in there in the first place is good
news, so no worries!

-- 
Jens Axboe

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6803A225A29
	for <io-uring@vger.kernel.org>; Fri,  5 Sep 2025 19:21:59 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.47
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757100121; cv=none; b=o7l4646I4b0/7ZQg9vrpnD/NdlzpIPJjPiJjjjjtFz2sBNgC0bM+FVG9GlkQ3J56Hsu8d6iJXfA93U5OoJ8Hs/DDFufTxUhkggozMsdxEA0NNTFfgo+WduGQC3sRhU0TUhyFlwghlXl2yCIS2cecaYXNeA+tUIocmY+MxYc3TNU=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757100121; c=relaxed/simple;
	bh=R6ooe08nC2EWpv3FSCHgeNCtc8UkNLPlvlgfCM1aciE=;
	h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
	 To:Cc:Content-Type; b=d5HTLMa5foaiWHc82SsFW8ljyHOSDDJ4sq5PfUno6AWVXRva598xIq6BTdJsPVGRyN4Bhrso+uey9GLS1UWpu5WEkZ/Gkm3v9kk8jyPv9oiN3X945bSGqMwmyK/tWwV5GWpeNnZz0iYs66L+mzYpnkAyOjh6v7UJ8/pQ9XtcSGs=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org; spf=pass smtp.mailfrom=linuxfoundation.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=Ek3nPnwE; arc=none smtp.client-ip=209.85.208.47
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linuxfoundation.org
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="Ek3nPnwE"
Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-61d7b2ec241so2961296a12.0
        for <io-uring@vger.kernel.org>; Fri, 05 Sep 2025 12:21:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linux-foundation.org; s=google; t=1757100117; x=1757704917; darn=vger.kernel.org;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=TxlnLct1A8sIha5mqHO/QsisosQcW7PWcvbt4ZguHk0=;
        b=Ek3nPnwEjg2FmGWUvEXiEX1GPC6cr2ay+dmIlmQxZPJ5/AUaHivW4RjADVtkodDWum
         40csRzryWElME9xGEu18wByIGJXcTLIU0pRb+GK6Bs9tMxkjAN+wamIiNXjw2+KxaET1
         SDYuTq4bAyXG0QmPDexlPnRQTJaNKRsQ75kWU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757100117; x=1757704917;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=TxlnLct1A8sIha5mqHO/QsisosQcW7PWcvbt4ZguHk0=;
        b=t+fwJ1OcJrQ+xB1lkWapVObJ887Hsmeuvj1v9Ac3chNazPfgYTGFNHV/XAHO+LyvWZ
         Q8C0OTnk2u1pTJjUAgZQLcxGFmOgQMLkf0eq5+H5rZZYhIV1weIfAykVXfJ+eERuVBF0
         tBhiMlLD0V5IfzPtFQJ6H0h16GdowQYDp6G0smbYdg5nZEWM8ZibJeFM+c9OT+UVIOUt
         8o+S+ZFet8/WcLHmRZZ9MmCigVmA8KiBsbYJz1tY2Ip3jlkE02vBW3Lb+Q5d1LLdo1jN
         LghZ8nCE1m+2atz/PHxlppAUae2nX0RH7LTN3oArzB9eLKF2bphH5c4BgT8c0k/lysi/
         8+Rw==
X-Forwarded-Encrypted: i=1; AJvYcCUxz4gP3IHB5otTRoowotyYJh8+N3w7NYwkZUb+Dl6kPOtpSIMAZM7rcFCiM6Qo/3WNf1G3ZGMRwg==@vger.kernel.org
X-Gm-Message-State: AOJu0YwXOjtOMfeDE85xou517IXGSrihtrMB+IgbWSRv5MtgEnobaNNT
	5ScVOYofEEen6cKvvlKHC7RWuMw1d1z+zY+kgzMKx0lODZoRn6t+IJEknuRmERNAqLGyrZTrS4M
	2i6p9f34=
X-Gm-Gg: ASbGncs+G/eNu5G0hvOdOt0V0rDkzgf9Fwng8M0+l4+2KJlKH4mby3Ynix3HvZTD0ZO
	2bZXUjoY7cNQVHDqF9Yc2hM/+7Sp+wlrNMOGIOApqz1v54URBnp87rx53zaHb7HeuI6lTi+osoT
	NkFTxMHgzoAi89RUIlaStrYby1GZLRcj3aySgcuac7mqMleOeZMnY9c4ZVMmq3AqVmYiGJUdecW
	wRGFMQ8IV6WokjmZr6VrjQbVuh3fvr9HwPhksnvBhw0JIMI00ZYFMFiAZAMRiJ3wovtCtjv8mYc
	GOcON+Mm50Q8+jAaRtW1EOcr1QlkBeKNt2xN0zTMsTqPRz0NttqyDQ65511FOtvEizulYHsNHXP
	JxLD2u2y6EFn7vErPt9hBBDZ9T16v7c0bNaiMLeWHqAgYywuan+/y5K3wmaF4zj4imdR4b2TdSO
	qQi8zIVq9QaHu2uBKXPA==
X-Google-Smtp-Source: AGHT+IFtd5A3dlTIuf79VdsksxGDwNDDfQgE7O1A5yOsbhfQIaui6bRBB1x39ffB/jfuT7clYlAvQQ==
X-Received: by 2002:a17:907:9815:b0:b04:3a69:eba4 with SMTP id a640c23a62f3a-b043a69f41dmr1952995866b.39.1757100117305;
        Fri, 05 Sep 2025 12:21:57 -0700 (PDT)
Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com. [209.85.218.43])
        by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b04189de5b5sm1426968066b.10.2025.09.05.12.21.56
        for <io-uring@vger.kernel.org>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 05 Sep 2025 12:21:56 -0700 (PDT)
Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-b0472bd218bso444690866b.1
        for <io-uring@vger.kernel.org>; Fri, 05 Sep 2025 12:21:56 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCXa3bQdoNdtET8uxlKDPvtNAbcysAzrFS1PH4jn795ZOB4S04lq8c9fT7BW9TE+ByVvb+xPHZKk3w==@vger.kernel.org
X-Received: by 2002:a17:907:c27:b0:afe:63ec:6938 with SMTP id
 a640c23a62f3a-b01d8a308b8mr2375796766b.7.1757100116274; Fri, 05 Sep 2025
 12:21:56 -0700 (PDT)
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com> <f0f31943-cfed-463d-8e03-9855ba027830@kernel.dk>
In-Reply-To: <f0f31943-cfed-463d-8e03-9855ba027830@kernel.dk>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Fri, 5 Sep 2025 12:21:39 -0700
X-Gmail-Original-Message-ID: <CAHk-=wgkgSoqMh3CQgj=tvKdEwJhFvr1gtDbK7Givr1bNRZ==w@mail.gmail.com>
X-Gm-Features: Ac12FXygnYtRIH9nr5tXEV1QvaMdVOZ264tcotmz50PfCGumA8novTsiKdvSe8c
Message-ID: <CAHk-=wgkgSoqMh3CQgj=tvKdEwJhFvr1gtDbK7Givr1bNRZ==w@mail.gmail.com>
Subject: Re: [GIT PULL] io_uring fix for 6.17-rc5
To: Jens Axboe <axboe@kernel.dk>
Cc: Caleb Sander Mateos <csander@purestorage.com>, io-uring <io-uring@vger.kernel.org>, 
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"

On Fri, 5 Sept 2025 at 12:04, Jens Axboe <axboe@kernel.dk> wrote:
>
> What is the hurt here, really, other than you being disappointed there's
> nothing extra in the link?

And just to clarify: the hurt is real. It's not just the
disappointment. It's the wasted effort of following a link and having
to then realize that there's nothing useful there.

Those links *literally* double the effort for me when I try to be
careful about patches.

So the "what's the hurt here" question is WRONG. The cost is real. The
cost is something I've complained about before.

I'm tired of having to complain about this, and I'm really really
tired of wasting my time on links that people have added with
absolutely zero effort and no thinking to back them up.

Yes, it's literally free to you to add this cost. No, *YOU* don't see
the cost, and you think it is helpful. It's not. It's the opposite of
helpful.

So I want commit messages to be relevant and explain what is going on,
and I want them to NOT WASTE MY TIME.

And I also don't want to ignore links that are actually *useful* and
give background information.

Is that really too much to ask for?

                 Linus

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-yx1-f49.google.com (mail-yx1-f49.google.com [74.125.224.49])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0ABC51FF1AD
	for <io-uring@vger.kernel.org>; Fri,  5 Sep 2025 19:23:56 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.49
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757100239; cv=none; b=ZFoq1hafFGMs6wXwTfY4BZDKnmPJk9SkisNXesWaoomxC0Iu9SJ1/0E1cXJLYwT3ThOSpX65DkkuTB0vsHxJD8KkxlIv4bbyI1jhocvUPxjQLl17BU05XRQgaNjLYsf6qG+1By4yJCAmGbz4hTFcJijgXI0KYxroP76rhUV+M+Q=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757100239; c=relaxed/simple;
	bh=DAzrUBYZwtbnfGozyw36W8kyyqia+hHgEUvMnkirV50=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=EN4Kgb/7K3G4MWIZiIptHRFCi/d4vnwu6lfhUXYPu57YUvAqpULJG/2luLim91rZQy//e1EmqpI23Ug91fwZm007eB0zOkz4O6t6VdbPgQYISsvO8il8oho7u9ya5ptrPV1AY+Mpj67HSie5tuKKeYhZubp/ZZzqAAbYaeTzXI8=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk; spf=pass smtp.mailfrom=kernel.dk; dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b=0hI+83e4; arc=none smtp.client-ip=74.125.224.49
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kernel.dk
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b="0hI+83e4"
Received: by mail-yx1-f49.google.com with SMTP id 956f58d0204a3-60479737d4cso128309d50.0
        for <io-uring@vger.kernel.org>; Fri, 05 Sep 2025 12:23:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=kernel-dk.20230601.gappssmtp.com; s=20230601; t=1757100236; x=1757705036; darn=vger.kernel.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=FOcaAtJRnFCVyknR8EKRy8AkJA4DWmnrZ3j3mQ7cyWQ=;
        b=0hI+83e4WMZ063f6to+d186po3rgsM5/Mb7mwhFAdWtUEbV8qzcxAt0Er9TtZf3G7G
         lIVtfWa8+nF/H60q1JtDzZjsIq+X4zGdkHir8jXP98FVVUg6YjEtLhC4NodUvk2rS+1J
         z7mGxOAbxHxxoOkQyatdAFoUDvIFAcWaUQqXt4+vp+MSSBgvIbTDk7QzrXfnq6rGL/s+
         u5c5JHY9eKXkdsUJeVDDKtNTRhX3Auhvs/3cgZhwrZvoKqHjLPw3JJ/5v9XgLdmmJitF
         Q6mEqf5r28C1c4UHN436eSxcRgZkeg1DyCdNVlnihUbMNww6UHLI3eKuG0oNFbdELCGa
         WV9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757100236; x=1757705036;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=FOcaAtJRnFCVyknR8EKRy8AkJA4DWmnrZ3j3mQ7cyWQ=;
        b=t+y5HA1bSgkCEzhy96jjo+VmWN4MmsDrKhafmSw2NQA30e1NXDYtQjkvHE7o+J8I22
         gvpOE7pSdAwNHTRRX6FfyNlLmjjIa9mgbTLGTVd8C4+0llEEee/JkDkJa8YWg5De7ZyC
         9MRj54NXuPN3Imtt9RI7wsMTXu6s9hParopuw4aEXfHQw/78sBR55SYQFL2kK0oTIw6I
         pMud5SVTdcTpTix6lDMX/WZ6CEd9z1EJlYYTH4byxUMRoZF6bHxbdsOENyy+kU3N/IlJ
         kO/BMREc5DVMOy24hC5BYJBjPpw9PsrP6LCWE7sEib5XRHEVey+G9rxCMfpuOAHYw6Eh
         5/Xg==
X-Forwarded-Encrypted: i=1; AJvYcCWxAITTlGWmXLx6BXdHdZGYLaIcQ1TjQ8WeSqSSom1deAB7dmqKDk+m06i/ezhOYBxstAFPdXBxDg==@vger.kernel.org
X-Gm-Message-State: AOJu0YyAuq1TEvGkiauTLM+5LflWRrEzysc336t7n96AYYSk22I7aDuR
	qywCWRfGq7hRdYK78MFyS6Y+r+QB8JBR9zJuQMWzR+s35jjWdoiRzASceQsEYID+wGw=
X-Gm-Gg: ASbGncuWqHHCuXCeJlAaDW8pcckKsK0FuetUv3WIXbmjciJj9H2kDcjFHp7q8XYhRji
	SE3RBoaXIDIqBRJAvgDmaS+NzxyKerkkP6YjM8eItYatkx91yynurkdlkpVaZqpmJDU+ZYbCGSi
	cvo5F4UtKjNIX5IdFVP7vip3G8oarJ1b0jPgbe7a5OEAMe4tt+rk/RhDffeYV0t6Mqt8jCuz6hj
	13BmTv/y88vIiXsAqXG73Z3/IA/cEAd1WH38tbpfY246gfLbSbZnONny2RYXf9fJKh2fTlQLEzL
	GBSBe9Ka/8Vp/Xu9wYwZQbdhVNzdIN+wkZ227BDzxug6vlYnlbHSyRqPsf8t7avkcg+ndTOO7KJ
	sRVGl/FIsRoGcylRKryo=
X-Google-Smtp-Source: AGHT+IGWDyFo3vZJl2AAeSnDBnU0spXfdg6K85ezZJaKYzh1+2xoWw4ebe4nhqg5Fq4S4ALzSVzdmw==
X-Received: by 2002:a53:ca4b:0:b0:5fd:dc27:e11f with SMTP id 956f58d0204a3-61028bc2afdmr123022d50.15.1757100235889;
        Fri, 05 Sep 2025 12:23:55 -0700 (PDT)
Received: from [172.17.0.109] ([50.168.186.2])
        by smtp.gmail.com with ESMTPSA id 00721157ae682-723a832e435sm31900587b3.26.2025.09.05.12.23.55
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 05 Sep 2025 12:23:55 -0700 (PDT)
Message-ID: <51f10765-1d74-48dd-8d5b-76178cf5dc66@kernel.dk>
Date: Fri, 5 Sep 2025 13:23:55 -0600
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [GIT PULL] io_uring fix for 6.17-rc5
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Caleb Sander Mateos <csander@purestorage.com>,
 io-uring <io-uring@vger.kernel.org>,
 Konstantin Ryabitsev <konstantin@linuxfoundation.org>
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
 <f0f31943-cfed-463d-8e03-9855ba027830@kernel.dk>
 <CAHk-=wi-jomx2=9jRbUz0F_AQ9vKs2uN42mPsEurYNQsUCJn-w@mail.gmail.com>
Content-Language: en-US
From: Jens Axboe <axboe@kernel.dk>
In-Reply-To: <CAHk-=wi-jomx2=9jRbUz0F_AQ9vKs2uN42mPsEurYNQsUCJn-w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 9/5/25 1:15 PM, Linus Torvalds wrote:
> On Fri, 5 Sept 2025 at 12:04, Jens Axboe <axboe@kernel.dk> wrote:
>>
>> IMHO it's better to have a Link and it _potentially_ being useful than
>> not to have it and then need to search around for it.
> 
> No. Really.
> 
> The issue is "potentially - but very likely not - useful" vs "I HIT
> THIS TEN+ TIMES EVERY SINGLE F%^& RELEASE".
> 
> There is just no comparison.  I have literally *never* found the
> original submission email to be useful, and I'm tired of the
> "potentially useful" argument that has nothing to back it up with.
> 
> It's literally magical thinking of "in some alternate universe, pigs
> can fly, and that link might be useful"

Then let's please define the rules. I always add a bug report in as a
Link tag, if it exists. I think we agree that's a good thing, because it
shows the origin of the patch and what it's supposed to fix.

If someone sends me a patch which may be a bug or a feature, add the
link IFF discussion actually happened there. Useful discussion,
presumably? Because what typically ends up happening is that someone
sends a series, and there's discussion, and then V2 is posted. Repeat
until good. When Vn is applied, there's zero discussion. But a link to
Vn is useful in that it helps you find Vn-1 and so forth, as it leads to
the cover letter. We can put the cover letter link in there, but that's
not useful in an big series, as it'd be in all the patches. Create
temporary branch, apply series, merge into branch where it belongs and
include the Link to the cover letter? Or the cover letter itself?

And probably more?

-- 
Jens Axboe

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 83D38278779
	for <io-uring@vger.kernel.org>; Fri,  5 Sep 2025 19:24:23 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.46
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757100265; cv=none; b=Tfn3pIw0nIbn02sqgsTx5fBI9aZ49P0mTN+OB0j97gn2JkqtcbOv1AfC3m7N5OL/FSfkr03rQqivvm6a6DF8qKBPSHWog2LFqSbMfNpFmf98XIvoKWpYhKnrxM9ENDP8kBmdX6FaF+k3JhY3bV63AYrB+YlVXdYB+zxGaF5UNYg=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757100265; c=relaxed/simple;
	bh=YQgaFRVScBR8CdN31XeTpzd8Co0aGjdN2SIVDDdkZYI=;
	h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
	 To:Cc:Content-Type; b=ufHxU19SEe2uvScaHAoRVbLP6X0J5Bt3v7KZx0GdpF7ZiVHDg/cGkDNw/gPtdXuVJDqfgFmWRHDPPy1r45DqikJLBwxp066I8qVk1mgkw9a1+DAmxLwUzZ4g0ruIpD2FqXylW9st+DVJzfR5+8jA52dy0ZL5EwFk362z8NJmrIs=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org; spf=pass smtp.mailfrom=linuxfoundation.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=X2XXkTkT; arc=none smtp.client-ip=209.85.218.46
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linuxfoundation.org
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="X2XXkTkT"
Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-b0475ce7f41so473646466b.1
        for <io-uring@vger.kernel.org>; Fri, 05 Sep 2025 12:24:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linux-foundation.org; s=google; t=1757100262; x=1757705062; darn=vger.kernel.org;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=LraTCc7ZDr/qseb9fCpwX5ASeZ9pStoMGqMFLaHyNCg=;
        b=X2XXkTkTz2D4DLIFr5YoIIANQfkk3HUvbEhe79OsHkP17feDzSLfAI4jOeboytxb2X
         Y6kLC3WJEifzKh+gcJzWq5wwCVf4g9dtd20xTCtv4O1lJjC2PlYNk950hfHIY9Qm+iKz
         5QHQGUeE8+Akg4BhJTuAE3C+/tD7p/lDt7cKY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757100262; x=1757705062;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=LraTCc7ZDr/qseb9fCpwX5ASeZ9pStoMGqMFLaHyNCg=;
        b=CwWsTrf0UMZZPE9ycls2DMydd+sJuMviggtkkI/gzPjELCSsuCIEOrfmaAUA/AkX/h
         l6XHNuVQuSu3l/HyeUEE9OL+4n5uh63Jf8tEvKdUGeqJO3YU9mEqpwgfxqMiSa3RiDpo
         hRj6wzfMHQ3IsIeDeJu+CNMStZ2erKkrNlcBLKlFSQ5Spp2coO9X3RGzlujetbk3n28n
         +GyJGStDuM2UJAslUOnN1nypWL1jRle+VuMA+BDlJB1bwriC55x0oN94a4GxOmocY0BL
         YEK1F8RJGD80rKfBN+GVugMXaXPGyTqLCeR0wVXjYHzxWdz5XxX5E6ZUV9xBAxVgQiRM
         B+VQ==
X-Forwarded-Encrypted: i=1; AJvYcCUTa9q7ANCE9Ji7sejOfjoZVtj8OrVaKR4aQyHaJasg2yL6Bdf15c97OfiJf+6VHLXvIRuHBoHDYA==@vger.kernel.org
X-Gm-Message-State: AOJu0Ywav2Hdz7Fu5MGsaBmS5INmSMzseMyooVSGXi1iYqtJ2EI5Y/ZC
	vHEoH1c63Ou7ZmfhySfSl2oclHULbVwaGJjNz+uLT+1in953jk2bApaSL5t7eAwXCFDLN6Syg5e
	Cn8xJh58=
X-Gm-Gg: ASbGnctRrm4dwyiI7XkeRA7PqRBaTEKqNAuKrYzu7RGNvXFsR6Dbo7dSPLbGaH7fYeu
	xkFpOsE0Z8tI4zgsNfJYAxoZagw5xKgcSECHHOx/n/YyqJqcFfTzbPsLDu32MjGGZBj/HEgbB2R
	wjb2iWwo2fCBdMkAGDx/XDhEkc8UZlxxujcNpSl00vkWl0W6dH5+ObDyGVWnLHuIk71jDQc6VFN
	Q3/iuBXWJBAsJvblG3N1OBWiONFMWfg2wmUcyRrF3nvErUaH8dsX4Ib/HoBYLyEWYDjfJcyFABu
	ECM/mUqODXVKxetIQHJj80M6JJhdpQst2rZHlksK7XfAz6kelUTjf1sEkxflvAohhXlVsuIVQdD
	s8jUOYFNkJRw0ZRUoB/Eebmmgcp448FQ3R0a0bS4x/HpuPhk3hXs32jIFMaM71ys9ME9wpuoZwY
	Y/AxmPnXf9rAhuTsPJ/g==
X-Google-Smtp-Source: AGHT+IGybl0JZ3MZP5VffIshdUipe0lGgY87QGKqM7XZEd0QwzX4s8W9/87AhWt58Zk4weGQOL2E0A==
X-Received: by 2002:a17:906:6a0b:b0:b04:ae7c:703e with SMTP id a640c23a62f3a-b04ae7c786cmr37236266b.24.1757100261614;
        Fri, 05 Sep 2025 12:24:21 -0700 (PDT)
Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com. [209.85.208.41])
        by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b0431832a98sm1248514766b.80.2025.09.05.12.24.21
        for <io-uring@vger.kernel.org>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 05 Sep 2025 12:24:21 -0700 (PDT)
Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-61ce4c32a36so4765460a12.3
        for <io-uring@vger.kernel.org>; Fri, 05 Sep 2025 12:24:21 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCVGx3TJSaA1V3yLwpxZ+69jXdbRpchjBN0aNH6ux4a6dGMrgG6peGx5CpPIEayhLJRvgUNbop8UJg==@vger.kernel.org
X-Received: by 2002:a17:907:1c1a:b0:b04:6338:c936 with SMTP id
 a640c23a62f3a-b0463391027mr1285634566b.17.1757099773481; Fri, 05 Sep 2025
 12:16:13 -0700 (PDT)
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com> <f0f31943-cfed-463d-8e03-9855ba027830@kernel.dk>
In-Reply-To: <f0f31943-cfed-463d-8e03-9855ba027830@kernel.dk>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Fri, 5 Sep 2025 12:15:57 -0700
X-Gmail-Original-Message-ID: <CAHk-=wi-jomx2=9jRbUz0F_AQ9vKs2uN42mPsEurYNQsUCJn-w@mail.gmail.com>
X-Gm-Features: Ac12FXy70hC-VxcARa1uOiuMe7T-lcPrYf6omHFP8_0CpXkjJOQa0QTa_RFLw8A
Message-ID: <CAHk-=wi-jomx2=9jRbUz0F_AQ9vKs2uN42mPsEurYNQsUCJn-w@mail.gmail.com>
Subject: Re: [GIT PULL] io_uring fix for 6.17-rc5
To: Jens Axboe <axboe@kernel.dk>
Cc: Caleb Sander Mateos <csander@purestorage.com>, io-uring <io-uring@vger.kernel.org>, 
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"

On Fri, 5 Sept 2025 at 12:04, Jens Axboe <axboe@kernel.dk> wrote:
>
> IMHO it's better to have a Link and it _potentially_ being useful than
> not to have it and then need to search around for it.

No. Really.

The issue is "potentially - but very likely not - useful" vs "I HIT
THIS TEN+ TIMES EVERY SINGLE F%^& RELEASE".

There is just no comparison.  I have literally *never* found the
original submission email to be useful, and I'm tired of the
"potentially useful" argument that has nothing to back it up with.

It's literally magical thinking of "in some alternate universe, pigs
can fly, and that link might be useful"

          Linus

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-yw1-f171.google.com (mail-yw1-f171.google.com [209.85.128.171])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id ABED821FF33
	for <io-uring@vger.kernel.org>; Fri,  5 Sep 2025 19:30:22 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.171
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757100626; cv=none; b=NxR/H5M9OQvUGKMmsRJi3gcLW9r4O60J6VwyDrGT5RpWb6xJgyrrztE7G4iCDQq1zpeklG+KdeyJckbH5UZ5ckrOsg9qjV+I5cTaC1KA9lx3qkPj+pM74Yfw57EUpTqqpotk4AKocso0TmW7tTi85YJGs7+mq4QZz83jkMap2/4=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757100626; c=relaxed/simple;
	bh=LIvLLzeWxngEMM03p/AmrSIdqWB80bRVcTwF4Db8KI4=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=n2imH7gjahbbNpuQQUY5WRLggMzsF2dTaZXp4W/OKupTYL8/4kZt6k01VrUoL6g5t1jR7BjskJh1jKZ6GxLvbcOz6c+wJ+COEDrwit90QjtrToUyyWrNwzNZ840/AX7Ip/jP+Qm8LDYSQBxGvCH/WIVNl3dzYwgJQohAgVX3Qi4=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk; spf=pass smtp.mailfrom=kernel.dk; dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b=B0grQHhQ; arc=none smtp.client-ip=209.85.128.171
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kernel.dk
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b="B0grQHhQ"
Received: by mail-yw1-f171.google.com with SMTP id 00721157ae682-723ae0bb4e4so28729767b3.1
        for <io-uring@vger.kernel.org>; Fri, 05 Sep 2025 12:30:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=kernel-dk.20230601.gappssmtp.com; s=20230601; t=1757100621; x=1757705421; darn=vger.kernel.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=UeCLZVR9qp4o8K0h7QYu1xDU39mEJgRdW0I1Y4sZcfI=;
        b=B0grQHhQKGW3jkTqY95aERSFWQW/ULIGUpbggRFfKWTiKsPt7JvBLSBCK3sOYEOeiC
         tGfY3yoILKGDIKUoGZeGRKqxidSQ4aiJLz6JyxKRVrUMichzvSsvANwH44uNad/XzRzb
         w1/s5tZDWdy/6LXjGV+YFtp2F6DM/eHiX2O/pDzD4Xtsx75BxazKrYQ3qqWAmJjBGJVg
         9Gwl0tbVlEnCCKGTt+g/1p+LgEspiR3+e9ZAuq/M3t0O6opar+MmFjuWOqzz/02DGWX1
         V3jz6GVg71+Y5d4iquJ3Nq0FJSOT5MxMKBNiggB146/Wct8x3xd4bZlZuvKoYIptqq+8
         pMtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757100621; x=1757705421;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=UeCLZVR9qp4o8K0h7QYu1xDU39mEJgRdW0I1Y4sZcfI=;
        b=qJZpZ4xoEdC3XzHUo55P52yqvYhW0EB9NTsaDVp6joqe+HQqHQ1+qLwedcEnZuoGcL
         z11PRU8tP4Zve+kN6Md8PyfZpIxGhP3+7Avng2B9SK4bdhNYTjrmTG6gALRseaxsewMc
         XjdZ01ZUi9W0DVHai1VvIOET/iCxX6qJqoSF0FM99/MwMVjIF6BDtT8z24B56Zi0IIpW
         fvldotomG+QD6ldQkFCBL5k7rlwErt9mvVYCYMOnHOlEHhu2fDQYEvaDrJJ7/3fhQISB
         +HcUmKVH6cmxr+71EhIEY3mtPLm4B021ee3zqEc9Flo3LvueSUHzHiPIhkShd5OCA1no
         FOgg==
X-Forwarded-Encrypted: i=1; AJvYcCVemrUeDejyU42rVOhfnEo1MwRa0d+gFLKQkuvwOcpI5oeS8jywv55HQgcyCwlUGBxeQFMo9quAoQ==@vger.kernel.org
X-Gm-Message-State: AOJu0YxPuMRGLZ4f+15Z0fzzSiLOSKAvz7YQ1sZX/DV2ysgYYlLrtuK9
	ECcR78Kl7qMJC1vLjulnR8lp2ow56DbJZDFymlcUqpXxDupdxBN1rPVZPc1R/VVGAOQ=
X-Gm-Gg: ASbGnctkajUPSFmnl7XmHAXzOASMcCqTTbgZuB//wHeRbIt4Sd4X8YQ4e5eCZKk5O15
	ME7DD5Kvo+gKyMxtpnyH4QIgg2PGnPA0qGz963FQFmlath8KLXI6mRe60os+EL5hx+FXd5zbkb/
	N3O/WNrmOHxGTdQFBArhFztpr0ebwW0A6X0kaOnnHlY9I7tBLi1eGrof9ogpPKiLujYqOusC7NK
	qEIUv08eEjPJWjQeo5e6HQRVDnSIinhZaIB1Wnk0AqF0Jg1GtclugH6gFyFPL4///daAhIYIp4N
	HaGsTgLPiC3fa0o/G9MYioE0fOivWrs/BmNfOQT/IsAlpnF1gbEm8YtRlzJOZ8nNAZWO5guBauL
	A/eBocs+IbIgOeuKTZi7c/mg323xSCw==
X-Google-Smtp-Source: AGHT+IG0gQO8H6mqRXwALtCbtcE7r45Vp1bxBcTphTjbS1pb5ua70uZIuVvidY9u/Sq0ntrl7dJ06A==
X-Received: by 2002:a05:690c:9688:b0:723:b94d:97cf with SMTP id 00721157ae682-727f4383b3amr461947b3.10.1757100621371;
        Fri, 05 Sep 2025 12:30:21 -0700 (PDT)
Received: from [172.17.0.109] ([50.168.186.2])
        by smtp.gmail.com with ESMTPSA id 956f58d0204a3-608110cabd6sm2004567d50.8.2025.09.05.12.30.20
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 05 Sep 2025 12:30:21 -0700 (PDT)
Message-ID: <72fb5776-0c50-42b8-943d-940960714811@kernel.dk>
Date: Fri, 5 Sep 2025 13:30:20 -0600
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [GIT PULL] io_uring fix for 6.17-rc5
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Caleb Sander Mateos <csander@purestorage.com>,
 io-uring <io-uring@vger.kernel.org>,
 Konstantin Ryabitsev <konstantin@linuxfoundation.org>
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
 <f0f31943-cfed-463d-8e03-9855ba027830@kernel.dk>
 <CAHk-=wgkgSoqMh3CQgj=tvKdEwJhFvr1gtDbK7Givr1bNRZ==w@mail.gmail.com>
Content-Language: en-US
From: Jens Axboe <axboe@kernel.dk>
In-Reply-To: <CAHk-=wgkgSoqMh3CQgj=tvKdEwJhFvr1gtDbK7Givr1bNRZ==w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 9/5/25 1:21 PM, Linus Torvalds wrote:
> On Fri, 5 Sept 2025 at 12:04, Jens Axboe <axboe@kernel.dk> wrote:
>>
>> What is the hurt here, really, other than you being disappointed there's
>> nothing extra in the link?
> 
> And just to clarify: the hurt is real. It's not just the
> disappointment. It's the wasted effort of following a link and having
> to then realize that there's nothing useful there.
> 
> Those links *literally* double the effort for me when I try to be
> careful about patches.
> 
> So the "what's the hurt here" question is WRONG. The cost is real. The
> cost is something I've complained about before.
> 
> I'm tired of having to complain about this, and I'm really really
> tired of wasting my time on links that people have added with
> absolutely zero effort and no thinking to back them up.

Like I said, I think there more fruitful ways to get the point across
and this picked up and well known, because I don't believe it is right
now.

> Yes, it's literally free to you to add this cost. No, *YOU* don't see
> the cost, and you think it is helpful. It's not. It's the opposite of
> helpful.

As a maintainer, yes it's free to add, and it removes the cost of
needing to think about this. Which is why lots of people just have -l as
the default. Exactly because then you don't have to think about it. I do
agree that this adds a lot of frivolous links, I think the mindset has
just been "well better to always have it there, rather than to never
even if you rarely need it".

> So I want commit messages to be relevant and explain what is going on,
> and I want them to NOT WASTE MY TIME.
> 
> And I also don't want to ignore links that are actually *useful* and
> give background information.
> 
> Is that really too much to ask for?

No I think that's fine, I'm mostly just complaining about the approach
in getting there. I think we all prefer the commit messages to be as
useful and relevant as possible.

-- 
Jens Axboe

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 45DDD29BDAE;
	Fri,  5 Sep 2025 19:33:15 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757100796; cv=none; b=QYykhPrK7o11UrKu2ckEHEDI1RS2sEZvJ5CumIPJZZDxAxPTS8dcG12oMIINZFSXnwfDBiQYd66etoWMi+hXuH8zwbHti0afzP1Mk6AASqrfsuu7dgaifMWrVir3gsasunOPgdsDt2T6TRPGd1fglqh5ZckYV0oW2hG5gU5Q3W4=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757100796; c=relaxed/simple;
	bh=cH92BEoAZ7B/hPjqgKWRCa6e6AzFGtNxEks4z2eYejQ=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=GiugYUxr50+tibkeRkXGmDAjODYqxKoIIveGv85UjBaW5ZvNXYWJp52WiRcz63zd8uE6RShEVYPxaUm71SY0NNGsnOw+rxXk/9z+J+WxwVsmOgtKW6NbSusuYjtxzS9nZfalsAdmHuHJI6J31ZS+REiHbeRUhqrCWNS2Wdibn1k=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=0990vW6A; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="0990vW6A"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A934FC4CEF1;
	Fri,  5 Sep 2025 19:33:15 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1757100795;
	bh=cH92BEoAZ7B/hPjqgKWRCa6e6AzFGtNxEks4z2eYejQ=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=0990vW6AZ8yObjk3Nt2vyPzAf71gNlm952V4intenD/lR4UPGJg6sgGcBX6BXlVdl
	 8MzL9V16oVs4MFmZvAQCl6MbBUw39LcPKmc2d4thKD9Hdsh1cE51VyA/NGnZq/tRBH
	 YL+ZnyVus4aMmcgXpgsn7HYhGe+uTuB4Zpnd8XaQ=
Date: Fri, 5 Sep 2025 15:33:14 -0400
From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jens Axboe <axboe@kernel.dk>, 
	Caleb Sander Mateos <csander@purestorage.com>, io-uring <io-uring@vger.kernel.org>, workflows@vger.kernel.org
Subject: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
Message-ID: <20250905-sparkling-stalwart-galago-8a87e0@lemur>
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
 <20250905-lovely-prehistoric-goldfish-04e1c3@lemur>
 <CAHk-=wg30HTF+zWrh7xP1yFRsRQW-ptiJ+U4+ABHpJORQw=Mug@mail.gmail.com>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAHk-=wg30HTF+zWrh7xP1yFRsRQW-ptiJ+U4+ABHpJORQw=Mug@mail.gmail.com>

(Changing the subject and aiming this at workflows.)

On Fri, Sep 05, 2025 at 11:06:01AM -0700, Linus Torvalds wrote:
> On Fri, 5 Sept 2025 at 10:45, Konstantin Ryabitsev
> <konstantin@linuxfoundation.org> wrote:
> >
> > Do you just want this to become a no-op, or will it be better if it's used
> > only with the patch.msgid.link domain namespace to clearly indicate that it's
> > just a provenance link?
> 
> So I wish it at least had some way to discourage the normal mindless
> use - and in a perfect world that there was some more useful model for
> adding links automatically.
> 
> For example, I feel like for the cover letter of a multi-commit
> series, the link to the patch series submission is potentially more
> useful - and likely much less annoying - because it would go into the
> merge message, not individual commits.

We do support this usage using `b4 shazam -M` -- it's the functional
equivalent of applying a pull request and will use the cover letter contents
as the initial source of the merge commit message. I do encourage people to
use this more than just a linear `git am` for series, for a number of reasons:

- this clearly delineates the start and end of the series
- this incorporates the contents cover letter that can give more info about
  the series than just individual commits *without* the need to hit the lore
  archive
- this lets maintainers record any additional thoughts they may have in the
  merge commit, alongside with the original cover letter

Obviously, we don't want to use the cover letter as-is, which is why b4 will
open the configured editor to let the maintainer pulling in the series make
any changes to the cover letter before it becomes the merge commit.

Having the provenance link in the cover letter as opposed to individual
commits makes perfect sense in this case, especially because it is now very
obvious where the series starts and ends.

This does create a lot more non-linear history, though. Judging from some of
my discussions on the fediverse, some maintainers are not sure if that's okay
with you. If that's actually your preferred way of seeing series being
handled, then I'll work on updating maintainer docs to indicate that this is
the workflow to follow.

Question -- what would be the preferred approach for single-patch submissions?
I expect having a merge commit for those would be more annoying?

> Anyway, the "discourage mindless use" might be as simple as a big
> warning message that the link may be just adding annoying overhead.
> 
> In contrast, a "perfect" model might be to actually have some kind of
> automation of "unless there was actual discussion about it".
> 
> But I feel such a model might be much too complicated, unless somebody
> *wants* to explore using AI because their job description says "Look
> for actual useful AI uses". In today's tech world, I assume such job
> descriptions do exist. Sigh.

So, I did work on this for a while before running out of credits, and there
were the following stumbling blocks:

- consuming large threads is expensive; a thread of 20 patches and a bunch of
  follow-up discussions costs $1 of API credits just to process. I realize
  it's peanuts for a lot of full-time maintainers who have corporate API
  contracts, but it's an important consideration
- the LLMs did get confused about who said what when consuming long threads,
  at least with the models at the time. Maybe more modern models are better at
  this than those I tried a year ago. Misattributing things can be *really*
  bad in the context of decision making, so I found this the most troubling
  aspect of "have AI analyze this series and tell me if everyone important is
  okay with it."
- the models I used were proprietary (ChatGPT, Claude, Gemini), because I
  didn't have access to a good enough system to run ollama with a large enough
  context window to analyze long email threads. Even ollama is questionably
  "open source" -- but don't need to get into that aspect of it in this
  thread.

However, I feel that LLMs can be generally useful here, when handled with
care and with a good understanding that they do and will get things wrong.

> For example, since 'b4' ends up looking through the downstream thread
> of a patch anyway in order to add acked-by lines etc, I do think that
> in theory there could be some "there was lively discussion about this
> particular patch, so a link is actually worth it" heuristic.
> 
> In theory.

Yeah, in practice we can't tell a simple "good job, here's a reviewed-by" from
a "lively discussion," especially if the lively discussion was about something
else that had nothing to do with the contents of the series (e.g. as this
thread). The clever-er we try to be with b4, the quicker we run into corner
cases where our cleverness is actually doing the wrong thing.

So, I'm generally on the side of "dumb but predictably so."

-K

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id C9B6D2AF00
	for <io-uring@vger.kernel.org>; Fri,  5 Sep 2025 20:10:16 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.49
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757103019; cv=none; b=IlAVTgLvhK2bNWZ4Qxp2cVNk2LLvlVhvqbLWlBnYy/rqx3xgYR/kdjIsI4mZK5WF4BEVbScin4DB1SZd15i7osLMvS14r34bX6RYqAPH2XuiefKVO3KsxdZrqKkHG0/wQfm+nm4+qcvINnEcocAamoUv4XcdqI5SiA21Yy1WVZs=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757103019; c=relaxed/simple;
	bh=ihZ/KBvVTM2viHT4uIXRQE2vVg3YunnikfyRSjOyZD0=;
	h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
	 To:Cc:Content-Type; b=N5Vs3wyp9I3s6H2NVsaexdBoDj54+vndZ2anpjzwfMc1seuRv38iAhNK7ACLQQxNcQc6C2PwDH7vjL6TB9e4EsN35GSe8ieAYm8Di08ulmIrStJUs46iJgVLXeD6jCSMB3QXoz5M8nfj0JwKjABoqLaBkVCY8nJeKrFKECx/HYI=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org; spf=pass smtp.mailfrom=linuxfoundation.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=XiA6swW2; arc=none smtp.client-ip=209.85.218.49
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linuxfoundation.org
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="XiA6swW2"
Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-aff0775410eso488796566b.0
        for <io-uring@vger.kernel.org>; Fri, 05 Sep 2025 13:10:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linux-foundation.org; s=google; t=1757103015; x=1757707815; darn=vger.kernel.org;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=xddsR/Pe+eD7cGTppeQ6zoun06h85L7v8WnJ4cYLHhY=;
        b=XiA6swW2YwGna0wpaiZQE6oStvn0paKdfaWmXPnedCWhxv3SUw9Z6ijTQ+68WNCM8I
         bkHhlTLb1Kkia20OdS44HHuC+/4aXPAC/E5pI5BUal4q72/8TtljxMRY5xGjgLxcZdtu
         USXIls/hFcVv8w/dd7pKgOsSjf1H63Q3yeMIE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757103015; x=1757707815;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=xddsR/Pe+eD7cGTppeQ6zoun06h85L7v8WnJ4cYLHhY=;
        b=LoFmu6Y9yQL6tB8ZsqaqMozVMjYDPmSJeQsnre6Fx+Lp7kcwpfFeCVEGxS7FnkqhXh
         FWWf79SRVCbweSvz0HbarC4T2xjzpAmMNhOZn1ftIGu1/4iC1NIneQO0yit+XoUexeWK
         s6ACaPc+lLZnOwILXQH/DTZA4gFHSqaxRFrXRoPqR4IlPgiA+d1CEd6f2ukAG3/S2spg
         dOMOyaSaNhV8CRuGG+lmMwEzcRhg2T+a1lKHrbwumuOcErPrH00aT6LA6QNWWcdCD8Rm
         xwZqaNWMkNJvyFM4e3VLIJBZqedN9DbxpV9sIo5eZRgmKIXBeyd5Qm3d66Wa2a0qrsR2
         5+kQ==
X-Forwarded-Encrypted: i=1; AJvYcCXg1OeaNe10ojg1NAX9kFtO/J3qbVMf7pKyu8Njk2hUzdcLoYs5PBJboCdXc/6KRyxKvzoVKW8ISQ==@vger.kernel.org
X-Gm-Message-State: AOJu0YxrYqdMmdxOH5szSsp23KeJhM44D4+fyreQjWuOsi1uZftwQVxo
	vELvn0hWW+K0JJnC8YuaetTMEzGQ8q/CmiUUkW8MBZNXhq3tIuxx2vwP2QHu+8sIsgkSxXw3Hx7
	1AR20N4Q=
X-Gm-Gg: ASbGncvekee1eBTyGRR5ZIn6Jx6gzWW0kdhSzqktbe0fkEXytHxaaNGyjw5OLK6BBfg
	LqIsDhxlBS+pplIUhpE9DwjZUvFFvVRBO13b9GMRL3VobFEUxCR+68R4aZ5e3Xs3tI2lb4qCeJT
	s+TP19ZDnb6BCfKGcv5j9X7/YrXnEUUagshKeiopy7iMF7zQdmZW2WLu+ZnHHGlJ9xBMyxNeIrE
	v8eSsP/pykdOJDE/54t208CLqx5Jka0lmeIuJY23w/pUuA9c8ofy6yql6j8Oyzms7KglY2wAWez
	avZfMT7mkRM86AYruYOwLNTfjjcfpC89hj0ADKyCmjAL1MhxJnytscy2ImVDKRglvjiVJudvCK3
	yAX/YV8Z5yNrlVpHS0w6rsefbjVA7sYoXBj6rat0QTI2JcMZavI6zI9TLOqWCd293e6nasqxiTg
	dkX5+qPp0=
X-Google-Smtp-Source: AGHT+IExIGeRt8o9rQ9Z7oDI9yPpGaAiOokN7L/o1XFCem7rAEZeIBZF9OS3Yk3LJcrTM/3sJuiEZA==
X-Received: by 2002:a17:907:3d91:b0:af9:70f0:62e3 with SMTP id a640c23a62f3a-b04931f4a7emr502249766b.15.1757103014783;
        Fri, 05 Sep 2025 13:10:14 -0700 (PDT)
Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com. [209.85.208.45])
        by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b01902d0e99sm1619621566b.12.2025.09.05.13.10.14
        for <io-uring@vger.kernel.org>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 05 Sep 2025 13:10:14 -0700 (PDT)
Received: by mail-ed1-f45.google.com with SMTP id 4fb4d7f45d1cf-619487c8865so6612239a12.1
        for <io-uring@vger.kernel.org>; Fri, 05 Sep 2025 13:10:14 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCV6uGXVTo3gh3VlPLF9Bfeec6iwwo/QqfW+48Epz/wxG8kmnyqLoWEdqV8kamH1O0YT46J3W2ckcQ==@vger.kernel.org
X-Received: by 2002:a17:906:dc93:b0:b02:d867:b837 with SMTP id
 a640c23a62f3a-b0493084d31mr511145266b.7.1757103013782; Fri, 05 Sep 2025
 13:10:13 -0700 (PDT)
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
 <20250905-lovely-prehistoric-goldfish-04e1c3@lemur> <CAHk-=wg30HTF+zWrh7xP1yFRsRQW-ptiJ+U4+ABHpJORQw=Mug@mail.gmail.com>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur>
In-Reply-To: <20250905-sparkling-stalwart-galago-8a87e0@lemur>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Fri, 5 Sep 2025 13:09:57 -0700
X-Gmail-Original-Message-ID: <CAHk-=wh7_K-8HxSuxvYAOiWy+1UkVyOs5qPLdZEj5bjn+-7PnQ@mail.gmail.com>
X-Gm-Features: Ac12FXyvC8KlB-60GW4lzH7j8EzgCz1sz-rbVM2idRV4lq9qeYgMZVtZcK0__N4
Message-ID: <CAHk-=wh7_K-8HxSuxvYAOiWy+1UkVyOs5qPLdZEj5bjn+-7PnQ@mail.gmail.com>
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for 6.17-rc5)
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: Jens Axboe <axboe@kernel.dk>, Caleb Sander Mateos <csander@purestorage.com>, 
	io-uring <io-uring@vger.kernel.org>, workflows@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"

On Fri, 5 Sept 2025 at 12:33, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> We do support this usage using `b4 shazam -M` -- it's the functional
> equivalent of applying a pull request and will use the cover letter contents
> as the initial source of the merge commit message. I do encourage people to
> use this more than just a linear `git am` for series, for a number of reasons:

I think that works well for more complex series, yes.

> This does create a lot more non-linear history, though. Judging from some of
> my discussions on the fediverse, some maintainers are not sure if that's okay
> with you.

I do *not* think it makes sense for random collections of patches, or
some minor two-patch series, no.

But I do think it makes sense for patch series that (a) are more than
a small handful of patches and (b) have some real "story" to them (ie
a cover letter that actually explains some higher-level issues).

Put another way: I would be unhappy if that model is used mindlessly.
No "let's automatically encourage this", please. That was, I feel, the
problem with "-l".

For example, just looking at things that happened today on lore, something like

  https://lore.kernel.org/all/20250905191357.78298-1-ryncsn@gmail.com/T/#t

looks like it could be handled very well with that actual merge model.
Just look at that cover letter: it has relevant numbers for the
series, exactly the kinds of things you do *not* want in individual
commit messages, but that make sense as a merge message.

That said, from what I've seen, these kinds of series are often MM,
and I don't think it matches the flow that Andrew tends to use. We
finally got Andrew to use git fairly recently, I'm not convinced
getting him to have a fancy non-linear history is in the cards.

(That said, Andrew clearly deals with series internally, and his pull
requests tend to actually describe things as such, so maybe he
wouldn't be too annoyed by something less linear).

I would worry a bit that  people would use odd merge bases for this.
Because one of the advantages of a linear history is that it's
simpler, and in particular that you only mess up the beginning point
of that linear history *once*. And yes, people do mess that up (we
have a whole section about the whole "pick a good base" in the docs
and people have gotten it wrong).

With non-linear history, there's just more complexity and getting
things wrong is easier and can be even more confusing.

So while I do think do that "b4 shazam -M" can be a very good thing, I
also think it's something that *definitely* needs a fair amount of
forethought.

It should not be some "default flow", in other words.

                 Linus

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 5A74919343B;
	Fri,  5 Sep 2025 20:47:30 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757105251; cv=none; b=kcptwtu0aNXp03D/KFJryobkwocJJZZE36uSfCIfjvMpdcskx1YTMbmRoBx/vGQp5z8xHK6lgOOPW9ZklDciJX7BiUVCi114LNbLvXZLkH2O0noBmUtXXjZg5cRl8LAGEI9An22ICJl+C14SsKgZrjlQXYS+ObCpVa5SgunynwY=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757105251; c=relaxed/simple;
	bh=X9QO4Gd/KqsySLQrKkXq9tZI7F0AC52LeY/MRkJxu6E=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=J6zqrKj6iF0h1uSFGjZjFTb+jYBtsPHqY4YWauL0dxwAyFrwWWDKbGjGHghHZGefULk1xxHthCqxr7wMJCPxTb+jFKFUXRYOZ0h6jT45TNWyhC8Rq2RCL3iiPThyc1eGqIim1yeQ2aC/gPEOsnTcGVBNJ/UetqvwjtCRoYeUPp0=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Mk2crzxX; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Mk2crzxX"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id AFF75C4CEF1;
	Fri,  5 Sep 2025 20:47:30 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757105250;
	bh=X9QO4Gd/KqsySLQrKkXq9tZI7F0AC52LeY/MRkJxu6E=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=Mk2crzxXJO6xwOHACqeatVuXJffjBBH0YwOsdPk8EVKc9VGKpHLyrX5M9pczlRGqO
	 msM7QuzgaM39hz09UJCRs9KhT/6XMehjMS5e/SvT87cnQivh2kuZiRT0TwrDzKYEe/
	 rdHkmXHIgQ7JlXtLctCX9pwWBcQEsfIDurmeDHfKg2yjlK+UoM41tn3td+WY3YeKJx
	 0KqDmUX8ISTwyY/P+iRZpYfoycevNHnYXXlOnQFk5bzQyBhG8HCTdw9PgKkRLwMImO
	 Rk7+lMJKctwGj4xLH/L0VGBT2A/Mq6C2UsX1if8FUYfv5w7FPSKx4xLRL+E7J2K4z0
	 QbVvRqIkuLJ0A==
Date: Fri, 5 Sep 2025 16:47:29 -0400
From: Sasha Levin <sashal@kernel.org>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>,
	Caleb Sander Mateos <csander@purestorage.com>,
	io-uring <io-uring@vger.kernel.org>, workflows@vger.kernel.org
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
Message-ID: <aLtMYVY_jD_HrTgg@laps>
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
 <20250905-lovely-prehistoric-goldfish-04e1c3@lemur>
 <CAHk-=wg30HTF+zWrh7xP1yFRsRQW-ptiJ+U4+ABHpJORQw=Mug@mail.gmail.com>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <20250905-sparkling-stalwart-galago-8a87e0@lemur>

On Fri, Sep 05, 2025 at 03:33:14PM -0400, Konstantin Ryabitsev wrote:
>On Fri, Sep 05, 2025 at 11:06:01AM -0700, Linus Torvalds wrote:
>> Anyway, the "discourage mindless use" might be as simple as a big
>> warning message that the link may be just adding annoying overhead.
>>
>> In contrast, a "perfect" model might be to actually have some kind of
>> automation of "unless there was actual discussion about it".
>>
>> But I feel such a model might be much too complicated, unless somebody
>> *wants* to explore using AI because their job description says "Look
>> for actual useful AI uses". In today's tech world, I assume such job
>> descriptions do exist. Sigh.
>
>So, I did work on this for a while before running out of credits, and there
>were the following stumbling blocks:
>
>- consuming large threads is expensive; a thread of 20 patches and a bunch of
>  follow-up discussions costs $1 of API credits just to process. I realize
>  it's peanuts for a lot of full-time maintainers who have corporate API
>  contracts, but it's an important consideration
>- the LLMs did get confused about who said what when consuming long threads,
>  at least with the models at the time. Maybe more modern models are better at
>  this than those I tried a year ago. Misattributing things can be *really*
>  bad in the context of decision making, so I found this the most troubling
>  aspect of "have AI analyze this series and tell me if everyone important is
>  okay with it."

Quick note on this: I observed the same thing, but found that using structured
format (i.e. lei q --format json) really helps with this issue.

>- the models I used were proprietary (ChatGPT, Claude, Gemini), because I
>  didn't have access to a good enough system to run ollama with a large enough
>  context window to analyze long email threads. Even ollama is questionably
>  "open source" -- but don't need to get into that aspect of it in this
>  thread.
>
>However, I feel that LLMs can be generally useful here, when handled with
>care and with a good understanding that they do and will get things wrong.

I'm facing a similar challange both for the AUTOSEL and the CVE work: there is
very little historical context in most commits, and the Link: tag is almost
always useless and just points to the final submission of a patch rather than a
relevant discussion around that code.

I ended up creating an AI agent that knows how to dig through both a local git
repo as well as our mailing list using lei-q and knows to search related
dashboards like kernelci, lkft, the syzbot dashboard, etc.

I'm not sure if at it's current form it's useful to anyone else, but here's an
example of what it generates on the patch in question:


Mailing List History for commit 0f51a5c0a89921deca72e42583683e44ff742d06
========================================================================

Author: Caleb Sander Mateos <csander@purestorage.com>
Date: Thu Sep 4 19:25:34 2025 -0600
Subject: io_uring/rsrc: initialize io_rsrc_data nodes array

## Timeline of Events

1. **October 25, 2024**: Jens Axboe commits major refactoring
    - Commit: 7029acd8a950 ("io_uring/rsrc: get rid of per-ring io_rsrc_node list")
    - Major rewrite eliminating per-ring serialization of resource nodes
    - Addressed resource reclaim stalls in networked workloads

2. **April 4, 2025**: Pavel Begunkov fixes related issue
    - Commit: ab6005f3912f ("io_uring: don't post tag CQEs on file/buffer registration failure")
    - Also fixes issues introduced by commit 7029acd8a950
    - Reference: https://lore.kernel.org/r/c514446a8dcb0197cddd5d4ba8f6511da081cf1f.1743777957.git.asml.silence@gmail.com

3. **September 4, 2025, 19:25 MDT**: Caleb submits initialization fix
    - Message-ID: 20250905012535.2806919-1-csander@purestorage.com
    - Sent to: io-uring@vger.kernel.org, linux-kernel@vger.kernel.org
    - Direct submission to Jens Axboe

4. **September 4, 2025, 19:50 MDT**: Jens applies the patch
    - Applied within 25 minutes of submission
    - No public review or discussion found

5. **September 5, 2025, 05:14 MDT**: Jens sends acknowledgment
    - Message-ID: 175707084146.356946.8866336484834458029.b4-ty@kernel.dk
    - Simple "Applied, thanks!" with b4 tool
    - Assigned commit: 0f51a5c0a89921deca72e42583683e44ff742d06

## Key Findings from Mailing List Search

### Minimal Public Discussion
- **No pre-submission review**: No RFC or v1 versions found
- **No public bug reports**: No KASAN, syzkaller, or user bug reports found that directly led to this fix
- **No post-submission discussion**: Only Jens' acknowledgment found
- **No testing tags**: No Tested-by or Reviewed-by tags

### Related Activity
- Pavel Begunkov's earlier fix (April 2025) shows the original refactoring had multiple issues
- Both fixes target error paths in the resource registration code
- Pattern suggests issues were found through code review rather than runtime failures


-- 
Thanks,
Sasha

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id CEE3C285CB9
	for <io-uring@vger.kernel.org>; Fri,  5 Sep 2025 20:54:22 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.53
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757105665; cv=none; b=SdzEtzhUiH/wtUlT9N/hh53FezVvmolZeZS0kZ8S4n3gsgy194bWWExAAVMyH5gt1OG38xBX13Gd20ci2PeksD77DdwNoA5B0D6PSK40Z3wNUQHRYgghl+Au8ktEtNwRg4pwFQG9HvPmMNeHTJ2aac7L11qHargLQykWMUg5Z/Y=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757105665; c=relaxed/simple;
	bh=MAf0SZO83um8RJakkKNX5oj2zVOPSjxCDK8t47hxPxs=;
	h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
	 To:Cc:Content-Type; b=aHIjgfuNvQaCbm2CisiYNzqhDZyUdDyAu8LbXvgrNuzURwgACP2D2iI+jy6kRmW8y5EyZ+K534ZY0c6TCMnCvZ8/WpnG+MXGFYpYaSiHBPx8kjzRFBsv08Xgh47ND3xde4LbmTjvSSe4lKxoS9J4TuqGm93w+YrOy4sxSC9KJlg=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org; spf=pass smtp.mailfrom=linuxfoundation.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=CSyvRoeK; arc=none smtp.client-ip=209.85.208.53
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linuxfoundation.org
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="CSyvRoeK"
Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-62105d21293so2653348a12.1
        for <io-uring@vger.kernel.org>; Fri, 05 Sep 2025 13:54:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linux-foundation.org; s=google; t=1757105661; x=1757710461; darn=vger.kernel.org;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=xeI5uxqqoARD89BnQ0NTAo1OVhNWzuVOTNFshiJtoyM=;
        b=CSyvRoeKcGOi7+3KpUQfH/ictYxQcL+PyLqV/Acol4OFBBumRK7PxpExKvzcA/1aYz
         +mB29za1VucwdBrrYZ/6kpBDV1XGVXuSthc+YBt+qZIqC+1rU2lKxVMimwtjRvW1p6rc
         /jolwbQvcNxyg7D2UoYEJpcb233U/DIlDbvNM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757105661; x=1757710461;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=xeI5uxqqoARD89BnQ0NTAo1OVhNWzuVOTNFshiJtoyM=;
        b=eUdpQ3Sxl2I/2HGfinV0kWPyPf7NpqVloZJCF5wP5Qh2ZbZrzmML3i/KOYWQ2ilSMG
         UOSbZEw9Wwj79cLR9eCM+lv6vX3GbaakPd9NZ/09eT/7bjJClGLLtaPN8qv+yus6Q7KO
         ijgdmXYcV7UxLY8zMROYgkgM5ZaZa5odi5/Ev0Nj1l6XPrbcnJub2eMuh6tLZysHa4zW
         3zfrIhqmylADZXwsUHtdzFPdZF2aj3Ss/1/XzXmtxfZW0aDHn8Es05XpN1RoA3nTQ0e8
         7Zs277p/eypzMDV71n7AZ4OXncEbMIpSaaN3PMuLhkmGcz6UTVkLPxj36aiJ5nBFlSAY
         T1UQ==
X-Forwarded-Encrypted: i=1; AJvYcCWszriEFIMC432qsz4EpyXlXM6cMifEyh2Pcllo+Eb9qIwFL6B4V1hEOC5ecMQnpBnayxuabd4t5Q==@vger.kernel.org
X-Gm-Message-State: AOJu0YzCqt3sKO3Hgee454QCPSr6AelFM6hOwgiDj+G5+1wXoMpcJ386
	KhlFcrDn2BwaiuwAGiDwE0XXdL/Bxh+/Wvpbl2xMV2IVTLu6gmwMD/ZSVM6mA0OxZ/35CkFLtBO
	pKrMSSF4=
X-Gm-Gg: ASbGncusDFk4WNixmUawN8KhwOYyL2Tb/DhEUv9TEj4BMw/qtfv2N9zw7LuxIRuPUSW
	Q06RI/n57GT3E0uj6Xvhc8bNxyAmZphffwv7XtVujqGdauaGk1mxGaEeArrTpDoxS2g1zDBfp91
	m/FC0KxpYcpFtJ3wb1p97o0wOeZmKpEXASZw9CYZQi1yD2/NZd063NuQ0BbD/CXXkXvBvXE734d
	YIPd0RjgunlN6I2SMtybecfetVdgH8s78SY525zgHRRnsr8trdqIIkGGOktZR9g9yyMCrDjfMTO
	YyUuepTf16YAXkdqf2G2yVfM9/WZEfHUqrxKggA59oE7XbC0nknpm6T/Py9KpBFdd0kTbT8a+o8
	Xfz2AaiyZrG4SKxbslisMga5ac/82Gp/RmqquwtjQoDDD7vAo0/aZ7KeGjQC66+30+tSZqlx1dr
	k2Rr0RcVk=
X-Google-Smtp-Source: AGHT+IE7yLQGj/tILYCRItBcVpvBvDeDoiyAJdHq+ttSZVQBd2GlmSR7f1FdjCxbIaSMiZ62dQz1nA==
X-Received: by 2002:a05:6402:26cc:b0:620:1030:1385 with SMTP id 4fb4d7f45d1cf-6237845b164mr301835a12.32.1757105660823;
        Fri, 05 Sep 2025 13:54:20 -0700 (PDT)
Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com. [209.85.218.44])
        by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-61cfc5575dcsm17180395a12.49.2025.09.05.13.54.20
        for <io-uring@vger.kernel.org>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 05 Sep 2025 13:54:20 -0700 (PDT)
Received: by mail-ej1-f44.google.com with SMTP id a640c23a62f3a-b0472bd218bso454850866b.1
        for <io-uring@vger.kernel.org>; Fri, 05 Sep 2025 13:54:20 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCWuiuOzZ8birnO6Oi+m4g3F12VX8+l3KtUXSr7by7kM8SqqEXmeGVGVuSEpuxyh1x6+ZGYk2EMOfQ==@vger.kernel.org
X-Received: by 2002:a17:907:1c10:b0:b04:1a80:35b9 with SMTP id
 a640c23a62f3a-b04b13cd575mr12690666b.12.1757105659694; Fri, 05 Sep 2025
 13:54:19 -0700 (PDT)
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
 <f0f31943-cfed-463d-8e03-9855ba027830@kernel.dk> <CAHk-=wgkgSoqMh3CQgj=tvKdEwJhFvr1gtDbK7Givr1bNRZ==w@mail.gmail.com>
 <72fb5776-0c50-42b8-943d-940960714811@kernel.dk>
In-Reply-To: <72fb5776-0c50-42b8-943d-940960714811@kernel.dk>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Fri, 5 Sep 2025 13:54:02 -0700
X-Gmail-Original-Message-ID: <CAHk-=wgdOGyaZ3p=r8Zn8Su0DnSqhEAMXzME91ZD9=8DDurnUg@mail.gmail.com>
X-Gm-Features: Ac12FXzEOlqgAVNuWTXpkSiFOW32U1HDNta-OqsyqUoOurQaAKrWT8aonma6-lc
Message-ID: <CAHk-=wgdOGyaZ3p=r8Zn8Su0DnSqhEAMXzME91ZD9=8DDurnUg@mail.gmail.com>
Subject: Re: [GIT PULL] io_uring fix for 6.17-rc5
To: Jens Axboe <axboe@kernel.dk>
Cc: Caleb Sander Mateos <csander@purestorage.com>, io-uring <io-uring@vger.kernel.org>, 
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"

On Fri, 5 Sept 2025 at 12:30, Jens Axboe <axboe@kernel.dk> wrote:
>
> Like I said, I think there more fruitful ways to get the point across
> and this picked up and well known, because I don't believe it is right
> now.

So I've actually been complaining about the link tags for years: [1]
[2] [3] [4].

In fact, that [4] from 2022 is about how people are then trying to
distinguish the *useful* links (to bug reports) from the useless ones,
by giving them a different name ("Buglink:"). Where I was telling
people to instead fix this problem by just not adding the useless
links in the first place!

Anyway, I'm a bit frustrated, exactly because this _has_ been going on
for years. It's not a new peeve.

And I don't think we have a good central place for that kind of "don't do this".

Yes, there's the maintainer summit, but that's a pretty limited set of people.

I guess I could mention it in my release notes, but I don't know who
actually reads those either..

So I end up just complaining when I see it.

And yeah, I will take some of the blame for people doing the useless
Link. Because going even further back, people were arguing for random
"bug ID" numbers. Go search lkml, and you'll find discussions about
having UUID's in the commits, and I said that no, we're not doing
that, and that a "Link:" tag to something valid is a good alternative,
and I even mentioned a link to the submission. So that could be seen
as some kind of encouragement - but it was more of a "no, we're *NOT*
doing random meaningless UUIDs".

I did go back and look in the git archives. The oldest link we have in
the kernel git tree is from 2011. Guess what? That email has had over
fourteen years to get more information associated with it on the
mailing list, but no.

That link has _zero_ new information that would be relevant outside
the commit that references it (f994d99cf140: "x86-32, fpu: Fix FPU
exception handling on non-SSE systems").

            Linus

Link: https://lore.kernel.org/all/CAHk-=wgfX9nBGE0Ap9GjhOy7Mn=RSy=rx0MvqfYFFDx31KJXqQ@mail.gmail.com/
[1]
Link: https://lore.kernel.org/all/CAHk-=wiUS4r788i5XjTtSwvfvKRm9uH2H5=eLHbZVu3Wo-YHCA@mail.gmail.com/
[2]
Link: https://lore.kernel.org/all/CAHk-=whRBX0aQq1J5S5nHXE2GvXnQ5z+cqu=iTY9xU34kvYMzw@mail.gmail.com/
[3]
Link: https://lore.kernel.org/all/CAHk-=wgzRUT1fBpuz3xcN+YdsX0SxqOzHWRtj0ReHpUBb5TKbA@mail.gmail.com/
[4]
Link: [ .. too lazy to look up more .. ]

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-yw1-f176.google.com (mail-yw1-f176.google.com [209.85.128.176])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7DEBE17E4
	for <io-uring@vger.kernel.org>; Sat,  6 Sep 2025 00:01:03 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.176
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757116866; cv=none; b=pGPKQ+u0qcW1q0mVKM6SJAoQVJ6KsvLdfmf/blEkvNBEq1dpuYa090Sb2dCTnVcnM02ftMyA4T8jc7XmIyDcOFD+0mteJ/NpF4CmXdufdDKMe+vEsCwnAXs/l0l/7UiybbG3ECHEDYjoUIpZrUiWjSzFwNCuhTChPjjczvEqDxs=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757116866; c=relaxed/simple;
	bh=I745OuqVCT8PA+unjsPW/MIzIeXr2r5FQRf1y5CrGQc=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=rS1qnJS3YLZq2ZDo3N4vy1UXbhKoArwa/jfnNLIf66kJoE9jpTrBg6VJ5FCM6jfHi4vBwm5hX6AFUBx1zvObNlnrSFICI9vZgc5xG6HPJpWo7qqFNiaHiaR0XtUsI2OTEU9bM6WRwC3OA+NXJzGySItj5xMIIFoERqJrMPJ33lU=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk; spf=pass smtp.mailfrom=kernel.dk; dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b=Hsy/kPXc; arc=none smtp.client-ip=209.85.128.176
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kernel.dk
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b="Hsy/kPXc"
Received: by mail-yw1-f176.google.com with SMTP id 00721157ae682-71d603cebd9so32115777b3.1
        for <io-uring@vger.kernel.org>; Fri, 05 Sep 2025 17:01:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=kernel-dk.20230601.gappssmtp.com; s=20230601; t=1757116862; x=1757721662; darn=vger.kernel.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=O7hhVmn7ApxXnBvxlYHbulBxdrRJDIkG54twuFLOHOY=;
        b=Hsy/kPXcNfDk7rZkDa+1qz1HojYoC5IxIr3+/kpA/DXyzI92A6SHJXu//NQsd7kTTn
         Pxkhem+wcQIJOv6o5I4Lan80B5uZke4S+mZGdNw5k5M6X+Rz9PkRHuu5rGmNXJ30vcAY
         rAErdkpwLHQligSGDG5RIdMZC7zT1GlcetQQomWU3YkI2to8LsviEIBexI5orNx3TQ2c
         zjJB28xHvAXHmkSZe0uygTgH/YnopBixQe6exK2IPFlNSvucNjdSQQ0iGCfb+0KNq9KR
         DQQKlv4QrG81WGT3s/bS0kNIKCQ9rHt6g2/kr2u5p4iUilTY7yqkXfq6dAQJpj++hi38
         HP5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757116862; x=1757721662;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=O7hhVmn7ApxXnBvxlYHbulBxdrRJDIkG54twuFLOHOY=;
        b=LMy01bn5lkJmIIH/eIcxnch49ATBmBE/xFHlQcNlRtVCkguaD9HzM5bIw19EyKsNb6
         Wjk/Nwp6jxRXcuJqHhlG1+J7VIYOT0T2NakadZMZZouWEHr8mAWqvaZImmS1Q5AX3clN
         7ihMiMzBj0yhDyUDiPR5C4L5F76YyisPJ2wyeQUSWd0BInuExKlcQt/JmSZngCCc/zc5
         z5VRdMWj9RSbUF9cSIfheDh3ScoHRRsUFzt9PeLrs9DdviO9uH3+Z7KaelILR+zChZ/l
         UT7KpLuVc+W0xC84DpGGIjjndHHvYgGBuHTVWBcByQnXkr0Fi7iaga1ClfP3p+ZLxRx8
         VJqw==
X-Forwarded-Encrypted: i=1; AJvYcCVWFXL4h4isKk8kpyGLTI3JQnIyJ/3tAxEXiTLgRrYQRKPetY1G/1/IqZDjijaLW5CuljizBBl6sw==@vger.kernel.org
X-Gm-Message-State: AOJu0Yzt+7E/xuLYpvBHUQzBeVXT8ZIJoZhTEKZ6FE5o6f/W/hRk3nBD
	3UuziHZVXEemR9JYMbEoyPG6Xh0166bHfCB9ZB8TM1X/1gVx1jec5HaNUkFLZqrGcgo=
X-Gm-Gg: ASbGncureOHPGf7NgWGAMvRbrZqaDv2aBrcmdJwRRpS1wQZwsfMyZo8S9kIv0Daz8N6
	H2T8bcJtoEhN0H+/YEsoTqHDY4nrROxVkffe9TyYYkF6ileFQnctMeTpAgEEbkS7nH6xT8Cs/3O
	zQv/uwpz6HNm/mznv2V5mySdK76pk8Fbw1b+PXblDLaG/NoAx4QpSVnny/97IZlCZ+83dpw1guA
	2crONjj0xHj3Bgi6A0AwMMn1wzTGJzH3MCdi+bKhoJNnjAYEkLMZ784jJUXeRzxZkUpYk2d3Z5O
	NGXjP5A8F5Be4zcLDsenRkvco+nkDpZGdiT6Fnnpd5tiwFChC/TxRP32R23nrc/Cp7GiVbLbx0X
	WGwxsouFnmSRam+WAYiM9sg+XMEOLCA==
X-Google-Smtp-Source: AGHT+IHgNVCwtMI0/9guEHCsfNnNR1Dy8aWTaz1hyNxfBEFoTst4l6lSZRKX9+Wq18nZ+vqcEy2n/Q==
X-Received: by 2002:a05:690c:9a05:b0:722:8ee9:ad57 with SMTP id 00721157ae682-727f30ae187mr7545227b3.14.1757116862435;
        Fri, 05 Sep 2025 17:01:02 -0700 (PDT)
Received: from [172.17.0.109] ([50.168.186.2])
        by smtp.gmail.com with ESMTPSA id 00721157ae682-723a85ae106sm32907267b3.70.2025.09.05.17.01.01
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 05 Sep 2025 17:01:01 -0700 (PDT)
Message-ID: <a65abd25-69bd-4f10-a8b8-90c348d89242@kernel.dk>
Date: Fri, 5 Sep 2025 18:01:01 -0600
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [GIT PULL] io_uring fix for 6.17-rc5
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Caleb Sander Mateos <csander@purestorage.com>,
 io-uring <io-uring@vger.kernel.org>,
 Konstantin Ryabitsev <konstantin@linuxfoundation.org>
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
 <f0f31943-cfed-463d-8e03-9855ba027830@kernel.dk>
 <CAHk-=wgkgSoqMh3CQgj=tvKdEwJhFvr1gtDbK7Givr1bNRZ==w@mail.gmail.com>
 <72fb5776-0c50-42b8-943d-940960714811@kernel.dk>
 <CAHk-=wgdOGyaZ3p=r8Zn8Su0DnSqhEAMXzME91ZD9=8DDurnUg@mail.gmail.com>
Content-Language: en-US
From: Jens Axboe <axboe@kernel.dk>
In-Reply-To: <CAHk-=wgdOGyaZ3p=r8Zn8Su0DnSqhEAMXzME91ZD9=8DDurnUg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 9/5/25 2:54 PM, Linus Torvalds wrote:
> On Fri, 5 Sept 2025 at 12:30, Jens Axboe <axboe@kernel.dk> wrote:
>>
>> Like I said, I think there more fruitful ways to get the point across
>> and this picked up and well known, because I don't believe it is right
>> now.
> 
> So I've actually been complaining about the link tags for years: [1]
> [2] [3] [4].
> 
> In fact, that [4] from 2022 is about how people are then trying to
> distinguish the *useful* links (to bug reports) from the useless ones,
> by giving them a different name ("Buglink:"). Where I was telling
> people to instead fix this problem by just not adding the useless
> links in the first place!
> 
> Anyway, I'm a bit frustrated, exactly because this _has_ been going on
> for years. It's not a new peeve.

What's that saying on doing the same thing over and over again and
expecting different results...? :-)

> And I don't think we have a good central place for that kind of "don't do this".
> 
> Yes, there's the maintainer summit, but that's a pretty limited set of people.

That'd be a great place to discuss it, however. One thing I've always
wanted to bring up but have forgotten to, is how I'd _love_ for your PR
merges to contain the link to the PR that you got for them. Yes I know
that's now adding a link, but that's a useful one. Maybe not for you,
but for me and I bet tons of other people. At least if there's
discussion on it. But hey I'd be happy if it was just always there, but
it seems we disagree on that part.

What is clear, however, is that the rules on this aren't clear at all.

> I guess I could mention it in my release notes, but I don't know who
> actually reads those either..

I actually think a LOT of people read those. I do every week, and it
always goes on LWN too, for example.

But it does not have to be in the release notes. Just a separate email
with LWN/Jon CC'ed, and boom you have your story and people will see it.
And it doesn't need yelling. Alternatively, we discuss at the
maintainers summit, and come up with a set of rules that can get
documented. And then hopefully end up on LWN too. Honestly I had to
search in Documentation/ to see if we even have any kind of maintainer
documentation. Looks like we do, but who looks in there...

> So I end up just complaining when I see it.
> 
> And yeah, I will take some of the blame for people doing the useless
> Link. Because going even further back, people were arguing for random
> "bug ID" numbers. Go search lkml, and you'll find discussions about
> having UUID's in the commits, and I said that no, we're not doing
> that, and that a "Link:" tag to something valid is a good alternative,
> and I even mentioned a link to the submission. So that could be seen
> as some kind of encouragement - but it was more of a "no, we're *NOT*
> doing random meaningless UUIDs".

Maybe the problem is indeed in the name, it's very generic to call it a
Link. If you see "Closes: " you know exactly what it is, it's for some
bug tracker and you can click it and expect to see more info. Maybe
"Bug: " would be useful, or "Report: " or whatever - naming is hard. But
Link literally tells my brain, it's a link to the patch. Maybe there's
discussion there, maybe there's not. Because like or not, I do think the
generic nature of the name Link is part of the issue here.

-- 
Jens Axboe

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 31704130A73;
	Sat,  6 Sep 2025 11:27:07 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757158028; cv=none; b=GfXtjWf6jvFdGtPvj17uyXmaqY/hRSN2elEfY/4aZiwfwmIEIAM1PThhjuvZEmEpeA3QocH5UfcjBEuaLSfgGWx8G0UT+7aYqk13bpcBp8Wdjn/tW4F7ZBJFV43WA0XbLrN/PFyxxw4aNT2SdW8OInQoHmCR4E+0ls3KWyLZpAM=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757158028; c=relaxed/simple;
	bh=7zX4TNEVYNMqJvz5CRJPzq4tSr5NNVK4tEormnQdmjo=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=RfnuLLKCLFnfvopeNIVQ0n2tcdNLjEgDzw2eGJKE6ERGGzgsUCWIG4EXJgC/jJgv1q1UcBqH7aZTaARUgZMoFcEoJIX8WJfDy/jXJq0SOXlgLAV4cK2G42wJ2C0YZkzfI8tClB9voSbS8WHMhhyMv/aBQNN0NcyL9MSCSgX/D/g=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=CYAa3jge; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="CYAa3jge"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 54129C4CEE7;
	Sat,  6 Sep 2025 11:27:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1757158027;
	bh=7zX4TNEVYNMqJvz5CRJPzq4tSr5NNVK4tEormnQdmjo=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=CYAa3jgeOCLG8gO+q/JrWJXlNNsRaiLNLZHkzif5CG2Q1Wvz2hSvFZ3jApqE6bVuL
	 3aQClOis6aPUbGzgP6B9nMd2aDas9UPd7JeiIvnu5s51lNKbU35CGBtgqzQwVEZyy1
	 BO4PWHiKrz5oUw2H8Gc6/zH81etOZS4JrVIgYiI8=
Date: Sat, 6 Sep 2025 13:27:04 +0200
From: Greg KH <gregkh@linuxfoundation.org>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>,
	Caleb Sander Mateos <csander@purestorage.com>,
	io-uring <io-uring@vger.kernel.org>, workflows@vger.kernel.org
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
Message-ID: <2025090614-busily-upright-444d@gregkh>
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
 <20250905-lovely-prehistoric-goldfish-04e1c3@lemur>
 <CAHk-=wg30HTF+zWrh7xP1yFRsRQW-ptiJ+U4+ABHpJORQw=Mug@mail.gmail.com>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250905-sparkling-stalwart-galago-8a87e0@lemur>

On Fri, Sep 05, 2025 at 03:33:14PM -0400, Konstantin Ryabitsev wrote:
> (Changing the subject and aiming this at workflows.)
> 
> On Fri, Sep 05, 2025 at 11:06:01AM -0700, Linus Torvalds wrote:
> > On Fri, 5 Sept 2025 at 10:45, Konstantin Ryabitsev
> > <konstantin@linuxfoundation.org> wrote:
> > >
> > > Do you just want this to become a no-op, or will it be better if it's used
> > > only with the patch.msgid.link domain namespace to clearly indicate that it's
> > > just a provenance link?
> > 
> > So I wish it at least had some way to discourage the normal mindless
> > use - and in a perfect world that there was some more useful model for
> > adding links automatically.
> > 
> > For example, I feel like for the cover letter of a multi-commit
> > series, the link to the patch series submission is potentially more
> > useful - and likely much less annoying - because it would go into the
> > merge message, not individual commits.
> 
> We do support this usage using `b4 shazam -M` -- it's the functional
> equivalent of applying a pull request and will use the cover letter contents
> as the initial source of the merge commit message. I do encourage people to
> use this more than just a linear `git am` for series, for a number of reasons:
> 
> - this clearly delineates the start and end of the series
> - this incorporates the contents cover letter that can give more info about
>   the series than just individual commits *without* the need to hit the lore
>   archive
> - this lets maintainers record any additional thoughts they may have in the
>   merge commit, alongside with the original cover letter
> 
> Obviously, we don't want to use the cover letter as-is, which is why b4 will
> open the configured editor to let the maintainer pulling in the series make
> any changes to the cover letter before it becomes the merge commit.

I like this a lot, and just tried it, but it ends up applying the
patches from the list without my signed-off-by, which will cause
linux-next to complain when it sees that I committed patches without
that.

Did I miss an option to `b4 shazam`?  Does it need to add a -s option
like `b4 am` has?

thanks,

greg k-h

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 00D4927CB35;
	Sat,  6 Sep 2025 11:28:00 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757158081; cv=none; b=RZfQAtRVyQoqaysqKQBhiDaeqPWaUoz/eSRls411FNnoMqzPolMa2vOQf4TjkqUmY/ZodOfYt233c+QEEkIBLjqLu9VK2hgXf6qxltTUBc/ZX5E0FfQDfVj5VcsBtk62WZUM8jk/or2pAf+7ovc3oMujZEva+2PcwI9A8EB9Olw=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757158081; c=relaxed/simple;
	bh=UUlYB+wVVkdfngIGRkX7T7dpTPTGj1UM32R/16ho5FE=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=rZMFdASy/6wsrFxFNX2HhgVVIGFvpi976YcA/drrwmQfK/BvXDUC9q1VwAgiW8td65vwkwpBTsg/WBuCnSOh3f7ZTN2anxYLiQzKmcaYLXXRyq+kCLE0mZs6Dz/1h2uyikevr+tm1p+fyvvy3TFdMT3bySNvdV3SLXXnQ9+vcz0=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=1V/ROkYK; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="1V/ROkYK"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1AB6DC4CEE7;
	Sat,  6 Sep 2025 11:27:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1757158080;
	bh=UUlYB+wVVkdfngIGRkX7T7dpTPTGj1UM32R/16ho5FE=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=1V/ROkYK73OtQNbaZvgqEJVE+ZBS6vXh1OZbAMu+H9JrHr9vklgunOOsR1aHh+Dad
	 Wuk0fg8xwkYoq2Q/QxDqWzFQbg2XjtA3KZQOcwNPgjWhz3VKCK0Tvlpbdlj5nba9YF
	 3x2Lg1FdAZsJuACzkDG+Hx9gQfalBIXbF5OCoccM=
Date: Sat, 6 Sep 2025 13:27:57 +0200
From: Greg KH <gregkh@linuxfoundation.org>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>,
	Caleb Sander Mateos <csander@purestorage.com>,
	io-uring <io-uring@vger.kernel.org>, workflows@vger.kernel.org
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
Message-ID: <2025090633-calcium-legroom-586f@gregkh>
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
 <20250905-lovely-prehistoric-goldfish-04e1c3@lemur>
 <CAHk-=wg30HTF+zWrh7xP1yFRsRQW-ptiJ+U4+ABHpJORQw=Mug@mail.gmail.com>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <2025090614-busily-upright-444d@gregkh>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2025090614-busily-upright-444d@gregkh>

On Sat, Sep 06, 2025 at 01:27:04PM +0200, Greg KH wrote:
> On Fri, Sep 05, 2025 at 03:33:14PM -0400, Konstantin Ryabitsev wrote:
> > (Changing the subject and aiming this at workflows.)
> > 
> > On Fri, Sep 05, 2025 at 11:06:01AM -0700, Linus Torvalds wrote:
> > > On Fri, 5 Sept 2025 at 10:45, Konstantin Ryabitsev
> > > <konstantin@linuxfoundation.org> wrote:
> > > >
> > > > Do you just want this to become a no-op, or will it be better if it's used
> > > > only with the patch.msgid.link domain namespace to clearly indicate that it's
> > > > just a provenance link?
> > > 
> > > So I wish it at least had some way to discourage the normal mindless
> > > use - and in a perfect world that there was some more useful model for
> > > adding links automatically.
> > > 
> > > For example, I feel like for the cover letter of a multi-commit
> > > series, the link to the patch series submission is potentially more
> > > useful - and likely much less annoying - because it would go into the
> > > merge message, not individual commits.
> > 
> > We do support this usage using `b4 shazam -M` -- it's the functional
> > equivalent of applying a pull request and will use the cover letter contents
> > as the initial source of the merge commit message. I do encourage people to
> > use this more than just a linear `git am` for series, for a number of reasons:
> > 
> > - this clearly delineates the start and end of the series
> > - this incorporates the contents cover letter that can give more info about
> >   the series than just individual commits *without* the need to hit the lore
> >   archive
> > - this lets maintainers record any additional thoughts they may have in the
> >   merge commit, alongside with the original cover letter
> > 
> > Obviously, we don't want to use the cover letter as-is, which is why b4 will
> > open the configured editor to let the maintainer pulling in the series make
> > any changes to the cover letter before it becomes the merge commit.
> 
> I like this a lot, and just tried it, but it ends up applying the
> patches from the list without my signed-off-by, which will cause
> linux-next to complain when it sees that I committed patches without
> that.
> 
> Did I miss an option to `b4 shazam`?  Does it need to add a -s option
> like `b4 am` has?

Oh nevermind, it does support -s.  It's just not documented :)

let me go make a patch...

thanks,

greg k-h

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 949AB3FBB3;
	Sat,  6 Sep 2025 11:30:39 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757158239; cv=none; b=IJBXnzhgVOY3s86RxghB+nME/HJsZuEsVif+l+SEn2uKY7qrBDhEsGezxmdaQuyKnhU2WasDcUI6iVvBIMQCmE19ogeWygof0Dmhmy9aRlvR3s4FhpTFxD2CMq/VZ+csJz2h9dBh7xyP6n7d/MKV8HBkq1OpBxfy4XliPSb9als=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757158239; c=relaxed/simple;
	bh=EVORCTkqkwCRSMu3NUDPY1xsO1kW8QaI0S62v3I2cfY=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=kDWdemAFu0vGZmiOXSGc2QsWeoG0XuMlyS7oBxo81DYMbAJxKhl4bA+7+9OeUfuG+Dmn/VmSppNILUlW0FEpEu6SdrYaahZiHo+Ui55K9pYxDd07uTyYT7UlT9nZr2v9XOe/hHAbRP9F4fv89EvdJP0cVdkghjWkjoMf0PG6iPE=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=D8hNSAZy; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="D8hNSAZy"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id BA664C4CEE7;
	Sat,  6 Sep 2025 11:30:38 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1757158239;
	bh=EVORCTkqkwCRSMu3NUDPY1xsO1kW8QaI0S62v3I2cfY=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=D8hNSAZyCLamH9eCdoTrCXo3euObmNWA8q7cZHA7MrEe2VzapyF9psVbXpnBdNexM
	 gnJFSNQi6r5u4zSwXBphBO/H7b7eIiz8/uOLc7+G2TLHaQmWXO0aTALrfex+0RAHsl
	 8C/s4bfCsto1Scq3JcKU9/+CQ+K9dXX5uGfEzXJg=
Date: Sat, 6 Sep 2025 13:30:36 +0200
From: Greg KH <gregkh@linuxfoundation.org>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>,
	Caleb Sander Mateos <csander@purestorage.com>,
	io-uring <io-uring@vger.kernel.org>, workflows@vger.kernel.org
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
Message-ID: <2025090605-evidence-chomp-d442@gregkh>
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
 <20250905-lovely-prehistoric-goldfish-04e1c3@lemur>
 <CAHk-=wg30HTF+zWrh7xP1yFRsRQW-ptiJ+U4+ABHpJORQw=Mug@mail.gmail.com>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <2025090614-busily-upright-444d@gregkh>
 <2025090633-calcium-legroom-586f@gregkh>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2025090633-calcium-legroom-586f@gregkh>

On Sat, Sep 06, 2025 at 01:27:57PM +0200, Greg KH wrote:
> On Sat, Sep 06, 2025 at 01:27:04PM +0200, Greg KH wrote:
> > On Fri, Sep 05, 2025 at 03:33:14PM -0400, Konstantin Ryabitsev wrote:
> > > (Changing the subject and aiming this at workflows.)
> > > 
> > > On Fri, Sep 05, 2025 at 11:06:01AM -0700, Linus Torvalds wrote:
> > > > On Fri, 5 Sept 2025 at 10:45, Konstantin Ryabitsev
> > > > <konstantin@linuxfoundation.org> wrote:
> > > > >
> > > > > Do you just want this to become a no-op, or will it be better if it's used
> > > > > only with the patch.msgid.link domain namespace to clearly indicate that it's
> > > > > just a provenance link?
> > > > 
> > > > So I wish it at least had some way to discourage the normal mindless
> > > > use - and in a perfect world that there was some more useful model for
> > > > adding links automatically.
> > > > 
> > > > For example, I feel like for the cover letter of a multi-commit
> > > > series, the link to the patch series submission is potentially more
> > > > useful - and likely much less annoying - because it would go into the
> > > > merge message, not individual commits.
> > > 
> > > We do support this usage using `b4 shazam -M` -- it's the functional
> > > equivalent of applying a pull request and will use the cover letter contents
> > > as the initial source of the merge commit message. I do encourage people to
> > > use this more than just a linear `git am` for series, for a number of reasons:
> > > 
> > > - this clearly delineates the start and end of the series
> > > - this incorporates the contents cover letter that can give more info about
> > >   the series than just individual commits *without* the need to hit the lore
> > >   archive
> > > - this lets maintainers record any additional thoughts they may have in the
> > >   merge commit, alongside with the original cover letter
> > > 
> > > Obviously, we don't want to use the cover letter as-is, which is why b4 will
> > > open the configured editor to let the maintainer pulling in the series make
> > > any changes to the cover letter before it becomes the merge commit.
> > 
> > I like this a lot, and just tried it, but it ends up applying the
> > patches from the list without my signed-off-by, which will cause
> > linux-next to complain when it sees that I committed patches without
> > that.
> > 
> > Did I miss an option to `b4 shazam`?  Does it need to add a -s option
> > like `b4 am` has?
> 
> Oh nevermind, it does support -s.  It's just not documented :)
> 
> let me go make a patch...

And it is documented.  Ugh, nevermind, I need more coffee, sorry for the
noise.

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 AF9EC283FE0;
	Sat,  6 Sep 2025 13:51:38 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757166698; cv=none; b=HZNuQBvwI79KcBQbq4rv5Acj4c5uowilufC/5VXvnhnkgUB9bwYATTGOaCjAZ1wbb3MIp7BV8LVcjkbOL9f70Nis5FQswhEMFaU21+Ds2pnnC8HV++3WR1z3ZVLy+UlZRnKakHlF932XbVbb5Ihbze/CxyMBdfmrDLQa/FLhbdo=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757166698; c=relaxed/simple;
	bh=UsOZU8x6O2j2h5+PWtcrTLOL5O/0Xuhq8HGu99szL/c=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=L7TKmDC2rqyaw/flE9egEOlSl8zDUkLMpn7NcdD1D88tWPdmglD1Gf8AU6jf/G/zLVgiJ2WXOVZ+h9W13Gyv+fTcPRUSsNGObsDGb8QTDsZAbhBjKxDXPilZcUskCLl5M02L+bBMgaKTa1a14I8J8qfkKjncq0j+H79Pg5kbn2o=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=V14Xsm78; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="V14Xsm78"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1B758C4CEE7;
	Sat,  6 Sep 2025 13:51:38 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1757166698;
	bh=UsOZU8x6O2j2h5+PWtcrTLOL5O/0Xuhq8HGu99szL/c=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=V14Xsm78AIYPaG5nNZJINK5Ut0IJrPPvYhONtdGHlXvzGn/1X38WoUMEn98R+qhyR
	 yeX+HONE8axL+L/wiedgaxZKqeYOPepoimgdK6UoWzwFUyyVlGKrrPVAULGiXRmDhX
	 DsxJFth6hWtVpooaVVReH8LJeaU+ZueIhrcPZIp0=
Date: Sat, 6 Sep 2025 09:51:33 -0400
From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>, 
	Jens Axboe <axboe@kernel.dk>, Caleb Sander Mateos <csander@purestorage.com>, 
	io-uring <io-uring@vger.kernel.org>, workflows@vger.kernel.org
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
Message-ID: <20250906-almond-tench-of-aurora-3431ee@lemur>
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
 <20250905-lovely-prehistoric-goldfish-04e1c3@lemur>
 <CAHk-=wg30HTF+zWrh7xP1yFRsRQW-ptiJ+U4+ABHpJORQw=Mug@mail.gmail.com>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <2025090614-busily-upright-444d@gregkh>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <2025090614-busily-upright-444d@gregkh>

On Sat, Sep 06, 2025 at 01:27:04PM +0200, Greg KH wrote:
> > Obviously, we don't want to use the cover letter as-is, which is why b4 will
> > open the configured editor to let the maintainer pulling in the series make
> > any changes to the cover letter before it becomes the merge commit.
> 
> I like this a lot, and just tried it, but it ends up applying the
> patches from the list without my signed-off-by, which will cause
> linux-next to complain when it sees that I committed patches without
> that.
> 
> Did I miss an option to `b4 shazam`?  Does it need to add a -s option
> like `b4 am` has?

Yes, most of the time you'll want to run it as `b4 shazam -Ms`.

Unfortunately, `shazam -M` is not perfect, because we do need to know the
base-commit, and there's still way too many series sent without this info. We
do some magic trying to figure out where the series might belong (basically,
by comparing blob hashes and trying to find the tree with the same set of blob
hashes as in the patch), but it only works if you have the same local repo as
the contributor.

Best regards,
-K

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 828E0131E2D
	for <io-uring@vger.kernel.org>; Sat,  6 Sep 2025 15:32:20 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.41
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757172742; cv=none; b=bppxCYcTPn8LhyMAddBFuqg46xMa95wMxR/BkBOE8O1hOR53iS4T/uw2L712LQHa1INRO1Qh/7ZUVQusyBDPtu984LjidfAImdO+BEKNTyTHIugKS6sVKrQf27JknBDfoyjz6aJUQSN/nEr61FpLSjyuusBUfZhyhiU2RU9H5BQ=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757172742; c=relaxed/simple;
	bh=xKkl3DI8ulz4vlyTXEnWSAZzTPv6U0YxG+xFkiOc4Jw=;
	h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
	 To:Cc:Content-Type; b=KkMw1Urr8s6dB3CTgDzUziyvtVdapn+4XDbUS154OVcBiFl5uO0rPtDc+DyVA/Ssir60y5qPXQZOF2cSpLNYSqmGvlp2nqkXpYyGQVsll3T2S4kLcr3kWRD4jd+m+WzCdfOreJLS5PrWl40ll7MpB0hhr1YUemxSrHQosbbxPUM=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org; spf=pass smtp.mailfrom=linuxfoundation.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=hqclO7ZC; arc=none smtp.client-ip=209.85.218.41
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linuxfoundation.org
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="hqclO7ZC"
Received: by mail-ej1-f41.google.com with SMTP id a640c23a62f3a-b04ba3de760so48688366b.0
        for <io-uring@vger.kernel.org>; Sat, 06 Sep 2025 08:32:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linux-foundation.org; s=google; t=1757172739; x=1757777539; darn=vger.kernel.org;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=lncXm2cx4UB0yoqFu06gxrKnTE2tWicGtIvZ9ZZAkv4=;
        b=hqclO7ZChyCQfVbSPdNG46eGB+VvoFW7XRixCEayUQnoyOr74+FlpbNgqUJUpegvZF
         8lDBetmWNc4oIHma1+lj7xN2YEjtPEbeW83CwHNMj76962BQAfMpwAO2wEX7Deg1gaCY
         WjhzY+P4HCdPngSvmv2/8kNO87t+oAeF2Buac=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757172739; x=1757777539;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=lncXm2cx4UB0yoqFu06gxrKnTE2tWicGtIvZ9ZZAkv4=;
        b=rQ4OvYmx/7wkKHB/ZlnLR2pNtzBGrkAJTlGXbA90sxs1DNniC2+TuKo/8aeZn+937E
         ygNNb4oBj+FHwx/hMU8WQnlPthphEigt4aLMB5mUt0nyPHU8wL9GXRhdNVWoN6nLAmIT
         B5N3kKYjQop0jBU2DZP40v/cGrqndkQtASxSQ1VzdEK7PXImy4dU0LJ6IFl+z0hq0AiW
         u0fZfNqAMRQXSJFVQ+K275l3qsYtN+aKoD2j+K7LA0/tWtTNfF+4eiIIdViyQd2KjuoG
         vFjTUGmmk4m1x86JyqJoiCX1RbKjpzEFNo1lCxBYnD5Of9Nye0DuW/VD7pYjc68ec5wt
         F5Vw==
X-Forwarded-Encrypted: i=1; AJvYcCXit77Fhj5P229zopAhSG9kIl3aDLcCyXUBDx/LJvgMSDaLiLEQApSQTz8bthVUZ15Q1OYzUOtD4w==@vger.kernel.org
X-Gm-Message-State: AOJu0YyFI7bRHbeCG5nJxNP4UiN5S4gQsM11z88DzHXdzblq0dY/5Sau
	bG3HwScynL9hEY7dOMlVK2Q5S88T5Yr/EuuV7uwwvHFwEoghVnjgaV2EDSins4fk8KQVrUy4500
	KBqS/do4=
X-Gm-Gg: ASbGnctLj3NfhMlgOeewX/XZfUaNcnYG5nN/TyH2P2N7EHXl8H7f/cyyd7+73hgT7bn
	ZRoYrLhZzVQvOvJgtUlmeCAuZwWYHiqIYgtHko+dZWTFzU7a3+T6b6HRugdZhUyGDU4S9zkcaGr
	8kOHALBYJor3o71H86M9RKaAFoYHeUf3CCpcHnJp7c1Zov2I2NSa6nbVyT5GRiVUv+rGpy2Cx6v
	GMSAQaMBGwSst6cDUFVltXFXzjFPZUN/Bjy5XITAPG5sdhW/3p/L2BXMMlnCgQFP6nove6e241T
	6pnPy4m9aPzsZizmg7nKMifMvSc8U1Rc9bZnBzFg1sQtjtLds+N/yGtJg0RMH+Bu1EmVPT3xqHS
	bCRuwSp3VZJHaQC/m1vQZGvyRId5t0FBYUxjYZ/dGVbNZyJvBDAWrdV6AdFOsexYpnDz2ptKeVJ
	+3kTqw2R4=
X-Google-Smtp-Source: AGHT+IEk0vk/C/k0iAB037yaIMsdyanrFtjgnetnI1GsPnxJOtHCJ1jqRhc6lw0h4uzmnFhs/i0yyQ==
X-Received: by 2002:a17:907:3e8c:b0:b04:522c:e0f7 with SMTP id a640c23a62f3a-b04b16bf0fcmr207334666b.47.1757172738524;
        Sat, 06 Sep 2025 08:32:18 -0700 (PDT)
Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com. [209.85.208.43])
        by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b0444252c2dsm1250536066b.81.2025.09.06.08.32.17
        for <io-uring@vger.kernel.org>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Sat, 06 Sep 2025 08:32:17 -0700 (PDT)
Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-6188b72b7caso3554118a12.2
        for <io-uring@vger.kernel.org>; Sat, 06 Sep 2025 08:32:17 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCXek01JvAyspqwHfexcNmRkIRsWNKY2y5uM8cTkRQTuoUdLi61uRX8I2tYrB7g6ASQ4KVVhBfIayA==@vger.kernel.org
X-Received: by 2002:a05:6402:2682:b0:624:591d:42b7 with SMTP id
 4fb4d7f45d1cf-624591d47e4mr1934878a12.21.1757172736702; Sat, 06 Sep 2025
 08:32:16 -0700 (PDT)
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
 <20250905-lovely-prehistoric-goldfish-04e1c3@lemur> <CAHk-=wg30HTF+zWrh7xP1yFRsRQW-ptiJ+U4+ABHpJORQw=Mug@mail.gmail.com>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur> <2025090614-busily-upright-444d@gregkh>
 <20250906-almond-tench-of-aurora-3431ee@lemur>
In-Reply-To: <20250906-almond-tench-of-aurora-3431ee@lemur>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sat, 6 Sep 2025 08:31:59 -0700
X-Gmail-Original-Message-ID: <CAHk-=wh8hvhtgg+DhyXeJSyZ=SrUYE85kAFRYiKBRp6u2YwvgA@mail.gmail.com>
X-Gm-Features: AS18NWBgyVz1-mW-WIhIbKz5dg1cwF2msJfKl3srmWO6iJRnqem-dLPENbf07RA
Message-ID: <CAHk-=wh8hvhtgg+DhyXeJSyZ=SrUYE85kAFRYiKBRp6u2YwvgA@mail.gmail.com>
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for 6.17-rc5)
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: Greg KH <gregkh@linuxfoundation.org>, Jens Axboe <axboe@kernel.dk>, 
	Caleb Sander Mateos <csander@purestorage.com>, io-uring <io-uring@vger.kernel.org>, 
	workflows@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"

On Sat, 6 Sept 2025 at 06:51, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> Unfortunately, `shazam -M` is not perfect, because we do need to know the
> base-commit, and there's still way too many series sent without this info.

No, no. You're thinking about it wrong.

An emailed patch series is *not* a git pull. If you want actual real
git history, just use git. Using a patch series and shazam for that
would be *bad*. It's actively worse than just using git, with zero
upside.

No, the upside of a patch series is that it's *not* fixed in stone yet
- not in history, not in acks, not in actual code. So do *not*
encourage people to think of it as some second-rate "git history"
model. It's not, and it would be *BAD* at it.

Instead, embrace the "it's a patch series". You should *not* strive to
make "b4 shazam" think it should recreate the original git tree. not
at all.

Instead, it should be a "here's a patch series with a cover letter,
make a pretty history of it, delineate it with a merge, and save the
relevant information from the cover letter in the merge message".

Look, we already have subsystems that do that. I don't know if they
use b4 shazam - maybe they do, maybe they don't - but the end result
is what matters.

For example, the networking people use this model for small series of
patches, and you can see it in patterns like this (I picked a random
area, this is meant to illustrate the point, the commits themselves
are not relevant):

    gitk d2644cbc736f..f63e7c8a8389

and look at the kind of "pseudo-linear" history, where small series
are delineated with that separate branch and merge, but this is *not*
some kind of global history where people tried to keep original commit
bases around etc.

That kind of global history would be *worse* for the whole "send
patches by email" model.

So don't strive to replicate git - badly. Strive to do a *good* job.

Your comment about how you want to know the base commit makes me think
you are missing the point.

git is git.

And emailed patch series are a different thing entirely, and trying
for some 1:1 thing only makes things objectively worse.

                  Linus

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 CE8DE2222AF;
	Sat,  6 Sep 2025 18:50:50 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757184650; cv=none; b=j6VcXUWPCYgLEKYUNwq5pA9IMxpfsDQD6xQI1HUR1ZqfShfsG0tQ7iJyQUjrbJ7v0iUjuVZKGxNOSFJji9Su6u0KbfpGvSD8YOG1zA7g2xxcxmeTVtpj6w5XqGhtlruFxRdYJ0xQy6m8jvSUYN/dsXPvBxJgdk5eZ/FvTd5i1XQ=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757184650; c=relaxed/simple;
	bh=FxXZFlSUHRGwj45r/lRFUsNZzQNOYdefVc1ypWMBIeM=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=Ab2w3dEwv7JYGcU8PiX62Z/P/m9PzNtsJu2OIkVuYgF+FHTYm/TAehjfhmwW5HnPtVCP8BqySbH5qpqHE1nIp8HtrCEf7sogdEvYmJ2NYICMI4joRq/gEm/5Pawa6kGeg/R6jXKUTeFUGj+gFZulP5A0DnOLNWEY6rt6Rlxw6pg=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=cDeOnFku; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="cDeOnFku"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37245C4CEE7;
	Sat,  6 Sep 2025 18:50:50 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1757184650;
	bh=FxXZFlSUHRGwj45r/lRFUsNZzQNOYdefVc1ypWMBIeM=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=cDeOnFkuoQmpMTWI9WG5kzXFrafRp0OyPMQNGIL3DhCYUNeVCz3BbOwLrskAwOJht
	 x8aj5el9I9DSeONhE8SkPNxPDTF06QSZlZk4bZ4JOkco4fCo7Gv8oJTBwOyIWrpRZM
	 C4p43LcXQcdlC3V7XV5Wd1i0SaXReLg96VtEsO9I=
Date: Sat, 6 Sep 2025 14:50:49 -0400
From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Greg KH <gregkh@linuxfoundation.org>, Jens Axboe <axboe@kernel.dk>, 
	Caleb Sander Mateos <csander@purestorage.com>, io-uring <io-uring@vger.kernel.org>, workflows@vger.kernel.org
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
Message-ID: <20250906-macho-reindeer-of-certainty-ff2cbb@lemur>
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
 <20250905-lovely-prehistoric-goldfish-04e1c3@lemur>
 <CAHk-=wg30HTF+zWrh7xP1yFRsRQW-ptiJ+U4+ABHpJORQw=Mug@mail.gmail.com>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <2025090614-busily-upright-444d@gregkh>
 <20250906-almond-tench-of-aurora-3431ee@lemur>
 <CAHk-=wh8hvhtgg+DhyXeJSyZ=SrUYE85kAFRYiKBRp6u2YwvgA@mail.gmail.com>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAHk-=wh8hvhtgg+DhyXeJSyZ=SrUYE85kAFRYiKBRp6u2YwvgA@mail.gmail.com>

On Sat, Sep 06, 2025 at 08:31:59AM -0700, Linus Torvalds wrote:
> On Sat, 6 Sept 2025 at 06:51, Konstantin Ryabitsev
> <konstantin@linuxfoundation.org> wrote:
> >
> > Unfortunately, `shazam -M` is not perfect, because we do need to know the
> > base-commit, and there's still way too many series sent without this info.
> 
> No, no. You're thinking about it wrong.
> 
> An emailed patch series is *not* a git pull. If you want actual real
> git history, just use git. Using a patch series and shazam for that
> would be *bad*. It's actively worse than just using git, with zero
> upside.

The primary consumer of this are the CI systems, though, like those that plug
into patchwork. In order to be able to run a bunch of tests they need to be
able to apply the patches to a tree, so, in a sense, they do need to recreate
git as much as possible, including the branch point.

> No, the upside of a patch series is that it's *not* fixed in stone yet
> - not in history, not in acks, not in actual code. So do *not*
> encourage people to think of it as some second-rate "git history"
> model. It's not, and it would be *BAD* at it.

b4 will tell you if a series applies cleanly to the current tree, but I don't
think we make use of this with `shazam -M` -- we always try to parent it
against the indicated base commit. Is the recommendation then to always try to
use the latest tree and bail out if it doesn't apply?

> That kind of global history would be *worse* for the whole "send
> patches by email" model.
> 
> So don't strive to replicate git - badly. Strive to do a *good* job.

But people do want to replicate git, if only so they can run integration tests
in a more automated fashion. If I understand correctly, you suggest two modes
of operations:

1. recreate the tree exactly as the author intended, so that CI systems can
   run tests.

2. try to create a merge commit on top of the latest HEAD and bail if it's not
   working, letting the maintainer fix any conflicts on their own.

> Your comment about how you want to know the base commit makes me think
> you are missing the point.

No, I'm mostly implementing what people tell me they'd like to see. :) Someone
once told me that they really wanted to be able to treat mailed series exactly
like a pull request, hence why this feature exists. You're actually the first
person to say that this behaviour is not what we should be doing.

-K

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 09AD614A8E
	for <io-uring@vger.kernel.org>; Sat,  6 Sep 2025 19:19:58 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.53
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757186401; cv=none; b=XmvgVQuwZo3N9kEVj1Nh0wfdQ0tprCGi5kP7FtYwOUgE7JphBc0MfbtJgAR8LRRb2Icq9l8lrLhHPObEEda1J7W8IwgYsegBaGsQhdnyaaz0Pb/YWMzWLU5nAWXxOKU8U3HIZbZFsDjk/4kFgLuxiUDBzAlSdfHi6ur1SyXzNl4=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757186401; c=relaxed/simple;
	bh=hYHMszme6h8QbWvH4Ei1/na8KCiKNvcEeq5inZjAvsY=;
	h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
	 To:Cc:Content-Type; b=s3agERcXpLU5WaLgFrZ8tGbz3/Hht+80iRXe0y6wDbtm74tpDkUfRepXKHt6+WD7cFrGbgIE0/9T27PoqhU5q3YEU9FxyHWPKMJPPZZAWoOMrwv6TfP9/sau1/um9MLTbsTHEvkcaTD+QG3nXUm+taPUySC+Ma8LhItQcPc4mwI=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org; spf=pass smtp.mailfrom=linuxfoundation.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=fLHtMkAB; arc=none smtp.client-ip=209.85.218.53
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linuxfoundation.org
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="fLHtMkAB"
Received: by mail-ej1-f53.google.com with SMTP id a640c23a62f3a-b0472bd218bso533370366b.1
        for <io-uring@vger.kernel.org>; Sat, 06 Sep 2025 12:19:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linux-foundation.org; s=google; t=1757186397; x=1757791197; darn=vger.kernel.org;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=3PsyEfWtapZbpxI5NrN12+zjKIm+vlmcngHXhUnlngY=;
        b=fLHtMkAB/QEvsP77SqdyVp+65xrGRtjR/xWP+kHl1RQFQPBcMrLV0zgwHkEILwvlGR
         a/9gyeqrFtaJex7evaT354nEhueQumPeLeYimBDvCGcATEoHR5ga5wu0fy1P6s6aQvOI
         2Wiv86hKi+0DttEn+V+Uj5wg9IctZ1HXFTrAs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757186397; x=1757791197;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=3PsyEfWtapZbpxI5NrN12+zjKIm+vlmcngHXhUnlngY=;
        b=tbNXyImbIfYbdkcs0rQcJCaZCGQGOtTQIrNvtCP9REOpP+4vJLy9PfvPz8Djn1m/cp
         S083sRBNxnu0TGVYeOfTaOZwuBZ9rvGU9EEWzY0OUonWzaFgN5d1N1NDC/WdpLQJl8hV
         TzLs6RQJPvM3EV6iBTZ8WPxc756UHY3Q9Ik/fLv5MP4uM95hkKd/q5UIwOWvEA+vR7+e
         WQ9hD07eElhFNSfJNxReLoAwOQ9mhO6Hq9jV6UTSjT8R3cW9HcQULm/jk9dyXhQXWLnf
         LFY/Mi+/U7AsZd7qfssK3fL1eZotGHr/1w4pA/TMGoSjVKx/o6VAsUnU8fs8syF5B38y
         nykw==
X-Forwarded-Encrypted: i=1; AJvYcCWeYIkj/kL7PztcCFo8oKtug/x8aHPTO7zlX4rc7aQju62BRX6QdGmDA2+QrCrRJgRtmeIrn6FCPg==@vger.kernel.org
X-Gm-Message-State: AOJu0Yx5PHFyKCyhboCrAPIRAs++da1lBKUbjyYdtUbFrhGd8RygG3tn
	+XDtQqj9Rx+ffVCD4A1GAftbOf/ie7p4UD6KafCDW3xLv6Cs/jgLUvvvqBx6yzJhWh9mXQoKu0Q
	yFsuISqI=
X-Gm-Gg: ASbGnctKHgBM+7RM/Wow+zwdfT8/aD1MHmt5bFdeDrwl7GfPBWfkGnb5mKCgwT9YN0u
	j6NyM/mOZnHLsmboEkpIxtlFOa/P8TLWrY6cJovSfixmfvD6qH+n5041DkOXm+mE0id+rQV1+cI
	SJYT3HnNjsqeydCjtePByR/sn1G7JUHBYFR0GEyEnP5p+wyxOujsMRb7JEomHumRE9JtSwZuBN7
	5dn3kc4ztEAjX0tJ2uBJW84lj8iRcGn2ghdWwcmHOITeFfmtGk7PE5vBS5p9U49vBJ1jmqC1wFs
	OmDMknL+gqBhpYhlhLF7gmzi/436PLydY/9+RbQDOdjgLj/aVNV1g6Dbaivlc1opozeO8wpkAVQ
	hRdS2AztOnC0TCui4JC7WqKWxu9Vvt/c3Zw7kt4f0X2dTwqy2Ljz4PiQ610Cveg0Wl1/f0rjVme
	TjWFrvXKc=
X-Google-Smtp-Source: AGHT+IFxjkhn2hHwhfAOw9HhEmRLFUCQVVCHjfGT0i37s6pFuVGWb30Kb88mKGOJlP1n6TXW4WKRHg==
X-Received: by 2002:a17:907:2d8e:b0:b04:563f:e120 with SMTP id a640c23a62f3a-b04b16d641emr249244266b.53.1757186397247;
        Sat, 06 Sep 2025 12:19:57 -0700 (PDT)
Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com. [209.85.218.52])
        by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b04abb99e78sm267794666b.76.2025.09.06.12.19.56
        for <io-uring@vger.kernel.org>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Sat, 06 Sep 2025 12:19:56 -0700 (PDT)
Received: by mail-ej1-f52.google.com with SMTP id a640c23a62f3a-b0428b537e5so538484366b.3
        for <io-uring@vger.kernel.org>; Sat, 06 Sep 2025 12:19:55 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCVd6/QwfXWsz5xBQBs79kr7O14qkkPT6aIGuVEHZab7hZEft2z5A6U+V2Y2jTRBiA7ucdl+vB92AA==@vger.kernel.org
X-Received: by 2002:a17:907:1c10:b0:b04:1a80:35b9 with SMTP id
 a640c23a62f3a-b04b13cd575mr276185666b.12.1757186395623; Sat, 06 Sep 2025
 12:19:55 -0700 (PDT)
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
 <20250905-lovely-prehistoric-goldfish-04e1c3@lemur> <CAHk-=wg30HTF+zWrh7xP1yFRsRQW-ptiJ+U4+ABHpJORQw=Mug@mail.gmail.com>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur> <2025090614-busily-upright-444d@gregkh>
 <20250906-almond-tench-of-aurora-3431ee@lemur> <CAHk-=wh8hvhtgg+DhyXeJSyZ=SrUYE85kAFRYiKBRp6u2YwvgA@mail.gmail.com>
 <20250906-macho-reindeer-of-certainty-ff2cbb@lemur>
In-Reply-To: <20250906-macho-reindeer-of-certainty-ff2cbb@lemur>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sat, 6 Sep 2025 12:19:38 -0700
X-Gmail-Original-Message-ID: <CAHk-=wjVOhd6xt0TiSakQx9jKBBveQr8GZiqF6Y6M9Ti1suw-w@mail.gmail.com>
X-Gm-Features: AS18NWCb9_SlpOIYL1sw9Hdpl73ZkQWu1tJwuck0jHTJiMgA7QLGMXslNk_Anb4
Message-ID: <CAHk-=wjVOhd6xt0TiSakQx9jKBBveQr8GZiqF6Y6M9Ti1suw-w@mail.gmail.com>
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for 6.17-rc5)
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: Greg KH <gregkh@linuxfoundation.org>, Jens Axboe <axboe@kernel.dk>, 
	Caleb Sander Mateos <csander@purestorage.com>, io-uring <io-uring@vger.kernel.org>, 
	workflows@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"

On Sat, 6 Sept 2025 at 11:50, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> The primary consumer of this are the CI systems, though, like those that plug
> into patchwork

Yes, for a CI, it makes sense to try to have a fixed base, if such a
base exists.

But for that case, when a base exists and is published, why aren't
those people and tools *actually* using git then? That gets rid of all
the strangeness - and inefficiency - of trying to recreate it from
emails.

So I'd rather encourage people to have git branches that they expose,
if CI is the main use case.

For an example of how to do this right, look at what Al does. Recent
patch series posted at

   https://lore.kernel.org/all/20250906090738.GA31600@ZenIV/

is a good example, and notice Al saying:

  Branches are in
  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git #work.path and
  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git #work.f_path resp.;
  individual patches in followups.

in the cover letter.

In other words: if the series was exported from a git tree and you
have a base to use, why would it *EVER* be sane to then use 'b4
shazam' to get it?

So I think what 'b4 shazam' _should_ be looking at is when Greg says
"I like this a lot".

I think it should aim for supporting maintainers that apply patch
series as part of their workflow, not at CI tools that have the WRONG
workflow.

And yes, maybe fixing the CI tool workflow then involves having people
who post patch series post the git branch too.

I often find the git branches nicer for walking through some patch
series anyway. But it goes both ways: for short series, since I'm in
the MUA, just walking through five or six patches and replying to them
is simpler, for longer series that do more involved things, I find
doing a "git fetch" and then using git tooling to look at particular
_parts_ of the series can be a lot more powerful.

In fact, for long series that get reposted, just to not mess up my
mailbox I would generally prefer to just see the git branch over some
50-email patch bomb.

Maybe *that* would be a good addition for 'b4', where you can reply to
just the cover letter and say "Ack for this series" or explicitly
reply to particular patches - that might not even have been posted -
by mentioning their commit IDs.

That's my workflow much of the time, see for example

   https://lore.kernel.org/all/CAHk-=wgZEkSNKFe_=W=OcoMTQiwq8j017mh+TUR4AV9GiMPQLA@mail.gmail.com/

where I basically went through the series, and then replied to
individual patches.

I do like the "reply to individual patches" - even when I might
actually have looked at them in git - just because then I can quote
the part I reacted to. So I do think posting the patches makes sense
as long as it's not some excessive patch-bomb, but at the same time I
do know that a lot of patch series end up being of the type where
possibly dozens of people get cc'd, but only on the one or two patches
that are relevant to them.

And then the git workflow *really* shines, because it gets you that
context (and lots of people object to getting tens or hundreds of
patches in email when only one or two are relevant to them).

              Linus

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from ms.lwn.net (ms.lwn.net [45.79.88.28])
	(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 8CFBC23741
	for <io-uring@vger.kernel.org>; Sun,  7 Sep 2025 18:47:39 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.79.88.28
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757270861; cv=none; b=ZfO8Gjpb+H3jYHUaz4sNbTmaR3gxBk81GzbNbvf2zzAiIrDvSqxNCBiCFlWMJYd0cAZkbGInzvjdFE0dngsXbIjB730ycc06WkpGc7oJPFppg3adQJamP2Ga+T3qA/gpsxCAC4uBeVozytHL/DKn35Iv1Vpj1piIFMxP3unOgTI=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757270861; c=relaxed/simple;
	bh=KLPAPQig9CQDwMtRC7oPOJlFO1Wve3y8xv6yBggX+6I=;
	h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID:
	 MIME-Version:Content-Type; b=FBUMAa/iRAnkF1HoBc8OZ/CNu3T0UFZEz6v7yJQkVtqykhYckxahB5moGHL+ep+sA8bOJilDsGchlnq/dcMuNZXNWvqQKPWdx38Mdp9UMh7bUwgEgBr6yqMDx7nVcS3wEQkfNP4rSA/YfLM48StSjQJM1R91j4YxrYfOMDMG5Y8=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lwn.net; spf=pass smtp.mailfrom=lwn.net; dkim=pass (2048-bit key) header.d=lwn.net header.i=@lwn.net header.b=rjl9vFWb; arc=none smtp.client-ip=45.79.88.28
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lwn.net
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lwn.net
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=lwn.net header.i=@lwn.net header.b="rjl9vFWb"
DKIM-Filter: OpenDKIM Filter v2.11.0 ms.lwn.net 8760E40AD8
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lwn.net; s=20201203;
	t=1757270852; bh=KLPAPQig9CQDwMtRC7oPOJlFO1Wve3y8xv6yBggX+6I=;
	h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
	b=rjl9vFWbP1Ey3m329KM2wlTbd08ciWUFggT6xKMENkBqj+HR2snaOeoFvgukhI7O1
	 6NY2IiefNnZTvEgVWRru2cKRTHHQ1lYqs4btLMICXuZzEjGIzdjU0zuGrjdmrOEsS2
	 0UeXnJGQPPwhVSLvUSDbg/TMSlKtjDoA8h2phlRMkFl1W8DHgcamWZPXqah48G4Wxu
	 zWQ27UlIYMDio0REPko4DVGsWzo1//1Z7oE2kOnWXvjqNjAtKkQRFFIRvSAgCJ6ct+
	 OADrBkWvJgK4xyTRawEgl2Zx8mdC2Ig3XNsgNOgU7q3KvQsHBZ2SbXwDsruphO49bm
	 Jhast45NTAL8Q==
Received: from localhost (unknown [IPv6:2601:280:4600:2da9::1fe])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by ms.lwn.net (Postfix) with ESMTPSA id 8760E40AD8;
	Sun,  7 Sep 2025 18:47:32 +0000 (UTC)
From: Jonathan Corbet <corbet@lwn.net>
To: Jens Axboe <axboe@kernel.dk>, Linus Torvalds
 <torvalds@linux-foundation.org>
Cc: Caleb Sander Mateos <csander@purestorage.com>, io-uring
 <io-uring@vger.kernel.org>, Konstantin Ryabitsev
 <konstantin@linuxfoundation.org>
Subject: Re: [GIT PULL] io_uring fix for 6.17-rc5
In-Reply-To: <a65abd25-69bd-4f10-a8b8-90c348d89242@kernel.dk>
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
 <f0f31943-cfed-463d-8e03-9855ba027830@kernel.dk>
 <CAHk-=wgkgSoqMh3CQgj=tvKdEwJhFvr1gtDbK7Givr1bNRZ==w@mail.gmail.com>
 <72fb5776-0c50-42b8-943d-940960714811@kernel.dk>
 <CAHk-=wgdOGyaZ3p=r8Zn8Su0DnSqhEAMXzME91ZD9=8DDurnUg@mail.gmail.com>
 <a65abd25-69bd-4f10-a8b8-90c348d89242@kernel.dk>
Date: Sun, 07 Sep 2025 12:47:31 -0600
Message-ID: <87ecsiyu9o.fsf@trenco.lwn.net>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain

Jens Axboe <axboe@kernel.dk> writes:

> But it does not have to be in the release notes. Just a separate email
> with LWN/Jon CC'ed, and boom you have your story and people will see it.

No need for the separate email :)

Thanks,

jon

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from ms.lwn.net (ms.lwn.net [45.79.88.28])
	(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 A44A212B73
	for <io-uring@vger.kernel.org>; Sun,  7 Sep 2025 22:04:10 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.79.88.28
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757282652; cv=none; b=fRE8u1nC3paJhTL17M6nFz2teKwgcNuurNyZWinKWFYCLVllrYbENVFa4cddueyiP29kKuI1BnPIfy7vdZn7DSJtW00GMGDjzNFZ+Q48+CmwkJnAIS9Eejf4C+APoJJepjQna5ePoVhEaXwo5Z51p/tl/TQAWJM5LyC8O1hemGY=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757282652; c=relaxed/simple;
	bh=MuvNavY7rqb26WNG55L9Yfqn0nKcVjYYA9VZhE65y2I=;
	h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID:
	 MIME-Version:Content-Type; b=kI8Vngf2sRrkOsDLuTS/kNtU8HGEAjKRZgjT78eO17g9VK6I97FtSekeb/olRRZkubI4+PwHqsu1uXeataDtu8R8+b9GYtjAQZebAIqE2o0maZCtypALAsUv6XYmp1D6HV2bGRFg0njkkVSs5pQyxhcxeK6K74xg8+PPWc/FQvI=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lwn.net; spf=pass smtp.mailfrom=lwn.net; dkim=pass (2048-bit key) header.d=lwn.net header.i=@lwn.net header.b=jL2vQz6j; arc=none smtp.client-ip=45.79.88.28
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lwn.net
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lwn.net
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=lwn.net header.i=@lwn.net header.b="jL2vQz6j"
DKIM-Filter: OpenDKIM Filter v2.11.0 ms.lwn.net 652AA40AE2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lwn.net; s=20201203;
	t=1757282649; bh=629pRZZlUS4PjmwA4SGvzJAuJYTTNjZObLmPT1vhkio=;
	h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
	b=jL2vQz6jjR7PH2V/1rZup6Ly3jzCYGkFQqi8ESKVLWxTqthku4MrZImgMvz2wiSSI
	 7kRikpJnqlp+oMYPABDAVirc98xmcuUN7pZXQ2D5VrnvQ4EW68/Dur5jXnBCW3JHzg
	 uVURQ5+OhNqUGtKGWQ9inM3AAmZr6c+Ss9PRN6GD7eaYhb3C95bXXc9py6Fm5iZdLZ
	 BwhxMNgVHe1jVULFrLijxMQQGm1qZUqOSRa/cvYfEqpy2YhaNCEfqEG2/u7Qlo53pu
	 Fv0JXz6y+ZudKnS5T5iujq4nClI0J7xSGMkK44sDiHvNikRA9QBsjDTbS7AKP91HAd
	 ik2fWOik202Lw==
Received: from localhost (unknown [IPv6:2601:280:4600:2da9::1fe])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by ms.lwn.net (Postfix) with ESMTPSA id 652AA40AE2;
	Sun,  7 Sep 2025 22:04:09 +0000 (UTC)
From: Jonathan Corbet <corbet@lwn.net>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>, Linus Torvalds
 <torvalds@linux-foundation.org>
Cc: Jens Axboe <axboe@kernel.dk>, Caleb Sander Mateos
 <csander@purestorage.com>, io-uring <io-uring@vger.kernel.org>
Subject: Re: [GIT PULL] io_uring fix for 6.17-rc5
In-Reply-To: <20250905-lovely-prehistoric-goldfish-04e1c3@lemur>
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
 <20250905-lovely-prehistoric-goldfish-04e1c3@lemur>
Date: Sun, 07 Sep 2025 16:04:08 -0600
Message-ID: <87a535zzqf.fsf@trenco.lwn.net>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain

Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:

> On Fri, Sep 05, 2025 at 10:24:17AM -0700, Linus Torvalds wrote:
>> Yes, I'm grumpy. I feel like my main job - really my only job - is to
>> try to make sense of pull requests, and that's why I absolutely detest
>> these things that are automatically added and only make my job harder.
>> 
>> I'm cc'ing Konstantin again, because this is a prime example of why
>> that automation HURTS, and he was arguing in favor of that sh*t just
>> last week.
>> 
>> Can we please stop this automated idiocy?
>
> FWIW, Link: trailers are not added by default. The maintainer has to
> deliberately add the -l switch.

It's worth noting that our documentation suggests adding a Git hook to
add Link: tags automatically: Documentation/maintainer/configure-git.rst. 
I suspect a lot of people add such hooks years ago when it was all the
rage and have long since forgotten about them...  Not that I would be
such a person, of course.

It seems we should remove the recommendation?

jon

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11])
	(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 3C818188713;
	Mon,  8 Sep 2025 09:11:07 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757322668; cv=none; b=IIZkbFH/GJhqbWJwvrUVUQADfcz0YbjVma42LI3A6t6mWAuFr48TCiUkbjINKpIT6/j2mb+NfGrvv4xOlonX6yib6SXA+DW5mjWexnqmLH+xLzbGNExG/umaE/Bpcv3WVnG6X3BSxf8hf50/CBACLaxVXDfL7OcsrnOieHolDxk=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757322668; c=relaxed/simple;
	bh=cswmx7ptxpYIBCZQu6oWFXqzBcIcfFh6RwYlTTHdkRg=;
	h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID:
	 MIME-Version:Content-Type; b=HuqryV9XxXVO0FEG+3k/i/2z+3fbTXphIsOE0WxjCce91E1dCRcArBOeNckL1lYutJkw80+3TWz6wA2mAS6BK5pxDXctQG6QNjsC7KnxjPsZx0jx2QdRetOD8vIgBMBBqB2qeX2hC3O1PikfBugA33L/z2nm69tuFou7Q380CTE=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=g/d2qHvh; arc=none smtp.client-ip=198.175.65.11
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="g/d2qHvh"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1757322668; x=1788858668;
  h=from:to:cc:subject:in-reply-to:references:date:
   message-id:mime-version;
  bh=cswmx7ptxpYIBCZQu6oWFXqzBcIcfFh6RwYlTTHdkRg=;
  b=g/d2qHvhEKJfI9vmJHdpbfvMUQcCGlYn2KhFZwch9DgbuW/Mz1rinawy
   n1M7uzbAC90DiaiZtqIJdqIkeO4b7MYfjtkskyEZF/BjcABnryhoGi5NY
   XPD3M5+8iEBC3UyQyUlobw2ITIFVplQTrx3EfuQUwXo471w8tR1E9iulr
   xyRE7L5eAXBpq6ydt3clQUKeOavvtR0ZsIWz/86yqJDlRAZAhA087z8S/
   c4Yz3Fac9hZ/DGCZEMFI7FmEUodVEan7EXjyaGvFIA9bhJ8uHRL6eLv79
   dVXgnxrVRyK7LTJbvNXDqwpSwex+xj4sc+fsojnA5Ir24Cxd8sPt2NKNu
   A==;
X-CSE-ConnectionGUID: z0N8NgpQR+udhR41pyENTw==
X-CSE-MsgGUID: 8X9DsWOaTM+pO7QBOXltxg==
X-IronPort-AV: E=McAfee;i="6800,10657,11546"; a="69828564"
X-IronPort-AV: E=Sophos;i="6.18,248,1751266800"; 
   d="scan'208";a="69828564"
Received: from fmviesa004.fm.intel.com ([10.60.135.144])
  by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Sep 2025 02:11:08 -0700
X-CSE-ConnectionGUID: QZO9IXB9RWa+Fpw1hzTQdA==
X-CSE-MsgGUID: Pnp32DZySveLb1Wf6lspcQ==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.18,248,1751266800"; 
   d="scan'208";a="177946272"
Received: from carterle-desk.ger.corp.intel.com (HELO localhost) ([10.245.246.204])
  by fmviesa004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Sep 2025 02:11:04 -0700
From: Jani Nikula <jani.nikula@intel.com>
To: Linus Torvalds <torvalds@linux-foundation.org>, Konstantin Ryabitsev
 <konstantin@linuxfoundation.org>
Cc: Greg KH <gregkh@linuxfoundation.org>, Jens Axboe <axboe@kernel.dk>,
 Caleb Sander Mateos <csander@purestorage.com>, io-uring
 <io-uring@vger.kernel.org>, workflows@vger.kernel.org
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
In-Reply-To: <CAHk-=wjVOhd6xt0TiSakQx9jKBBveQr8GZiqF6Y6M9Ti1suw-w@mail.gmail.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
 <20250905-lovely-prehistoric-goldfish-04e1c3@lemur>
 <CAHk-=wg30HTF+zWrh7xP1yFRsRQW-ptiJ+U4+ABHpJORQw=Mug@mail.gmail.com>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <2025090614-busily-upright-444d@gregkh>
 <20250906-almond-tench-of-aurora-3431ee@lemur>
 <CAHk-=wh8hvhtgg+DhyXeJSyZ=SrUYE85kAFRYiKBRp6u2YwvgA@mail.gmail.com>
 <20250906-macho-reindeer-of-certainty-ff2cbb@lemur>
 <CAHk-=wjVOhd6xt0TiSakQx9jKBBveQr8GZiqF6Y6M9Ti1suw-w@mail.gmail.com>
Date: Mon, 08 Sep 2025 12:11:01 +0300
Message-ID: <882495028cfb73b2db0119a8c37e34a85344ce2e@intel.com>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain

On Sat, 06 Sep 2025, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Sat, 6 Sept 2025 at 11:50, Konstantin Ryabitsev
> <konstantin@linuxfoundation.org> wrote:
>>
>> The primary consumer of this are the CI systems, though, like those that plug
>> into patchwork
>
> Yes, for a CI, it makes sense to try to have a fixed base, if such a
> base exists.
>
> But for that case, when a base exists and is published, why aren't
> those people and tools *actually* using git then? That gets rid of all
> the strangeness - and inefficiency - of trying to recreate it from
> emails.
>
> So I'd rather encourage people to have git branches that they expose,
> if CI is the main use case.

For i915 and xe, we'll want *all* patches go through CI. I'm sure there
are other drivers like that. CI is not the "main" use case, just one use
case. I'd like to have patches on the list for review and discussion,
and git branches for CI and everything else.

Insert "Both? Both. Both. Both Is Good." meme here.

To me it sounds like it would be useful to have tooling (b4? git
send-email?) that could push a git branch *and* send those changes as a
patch series, with a well-formed, machine-readable part in the cover
letter that points at the git repo.

I guess you could have server git hooks or forge workflows to send the
patches as well.

(Though you still can't review what's on the list, and blindly apply
what's in the git repo.)


BR,
Jani.


-- 
Jani Nikula, Intel

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 8816F281375;
	Mon,  8 Sep 2025 11:59:46 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757332786; cv=none; b=ZKL9rRdsKzIsdWwiYeAYCt5aU/No8Jy5XQibJBQF+E1Idg5HI6uUtUZz/bVKX+kirUs8zcHX4OTWR0sXnx4WcwgUSJaauAwdJIXIwHG9cbbuhNACDhFyH8GjuO7PWCurRXvCl7uWE3FQbrxCJ93ybZcmcdmg/TpNqlkP8YmjS84=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757332786; c=relaxed/simple;
	bh=Z18dYGbVBxhQdrBJ9dFppbGyfSMxBu3aI+xNHdGsRY8=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=bq3rPHzRw/85Qf0fEG+dIU3aGptxXcZ71f6Su/7g+nX0SXOvheIrF8tH4slis9+Jetv4V+LL5/UFOtKKsWczkIA7BGdo8EHuucSXRTe2GvBZyjkN4uA7B43bR52yk6nKCq4fkgMQCLR9EwVzciInw4yL4HR6+UjiOum36RR4nEw=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=geT4ONah; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="geT4ONah"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9A280C4CEF1;
	Mon,  8 Sep 2025 11:59:44 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757332786;
	bh=Z18dYGbVBxhQdrBJ9dFppbGyfSMxBu3aI+xNHdGsRY8=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=geT4ONah7Ta5//y3PIOlrU1Dol+3QXefdse2eMuwWBvEmvtuZP+NtQMxesDyjj7gP
	 IHryqjAZvAe5VNlLmkG90gxclXBVTeesB+dHwRQROgkyzY2PyFqdU8K9VktawJXp+o
	 id5oizZ73ElSUnzzn2u9Mmczn7w+b9UCAVqmplb8EmxrlcJLNqsJkNk4oIBiQg/V0h
	 JLv93XejozRbTsjMZEw4lpb7L8DZWj441R7pGbB60FVXTdS2P0uwJ40c/oGsP0AV3B
	 VOq39sC6f8lNXV5DorGKqhUVAmEa2PsWR9vpzZMUnd5+ib/soZPCvP7EQF5ga8uJI0
	 tfNCl5JBesVYg==
Date: Mon, 8 Sep 2025 12:59:41 +0100
From: Mark Brown <broonie@kernel.org>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Greg KH <gregkh@linuxfoundation.org>, Jens Axboe <axboe@kernel.dk>,
	Caleb Sander Mateos <csander@purestorage.com>,
	io-uring <io-uring@vger.kernel.org>, workflows@vger.kernel.org
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
Message-ID: <684c2197-7cd4-4330-9a43-109c40fda9cf@sirena.org.uk>
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
 <20250905-lovely-prehistoric-goldfish-04e1c3@lemur>
 <CAHk-=wg30HTF+zWrh7xP1yFRsRQW-ptiJ+U4+ABHpJORQw=Mug@mail.gmail.com>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <2025090614-busily-upright-444d@gregkh>
 <20250906-almond-tench-of-aurora-3431ee@lemur>
 <CAHk-=wh8hvhtgg+DhyXeJSyZ=SrUYE85kAFRYiKBRp6u2YwvgA@mail.gmail.com>
 <20250906-macho-reindeer-of-certainty-ff2cbb@lemur>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="AVW3f+5yfb/QrPEv"
Content-Disposition: inline
In-Reply-To: <20250906-macho-reindeer-of-certainty-ff2cbb@lemur>
X-Cookie: Air is water with holes in it.


--AVW3f+5yfb/QrPEv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Sat, Sep 06, 2025 at 02:50:49PM -0400, Konstantin Ryabitsev wrote:
> On Sat, Sep 06, 2025 at 08:31:59AM -0700, Linus Torvalds wrote:

> > An emailed patch series is *not* a git pull. If you want actual real
> > git history, just use git. Using a patch series and shazam for that
> > would be *bad*. It's actively worse than just using git, with zero
> > upside.

> The primary consumer of this are the CI systems, though, like those that plug
> into patchwork. In order to be able to run a bunch of tests they need to be
> able to apply the patches to a tree, so, in a sense, they do need to recreate
> git as much as possible, including the branch point.

Well, for CI we often don't exactly care that the patch is applied in
the context that the sender sent it, we care more that the patch is
applied for testing in the same context where it's going to be applied
when merged.  The base information is useful and we might want to use
it, but we might also not.  My flow is to apply things, test and then
push to the actual tree if the testing is happy so I'm testing the
actual commits that will be pushed if everything goes well.

> > No, the upside of a patch series is that it's *not* fixed in stone yet
> > - not in history, not in acks, not in actual code. So do *not*
> > encourage people to think of it as some second-rate "git history"
> > model. It's not, and it would be *BAD* at it.

> b4 will tell you if a series applies cleanly to the current tree, but I don't
> think we make use of this with `shazam -M` -- we always try to parent it
> against the indicated base commit. Is the recommendation then to always try to
> use the latest tree and bail out if it doesn't apply?

If we're going to automatically pick up the base commit that needs an
option to limit what the commits that might be selected are, people
don't always send something directly usable.  For example with a series
that should be split between trees (eg, a driver plus DT updates to add
the device to some boards) you might reasonably base off linux-next,
that'll get a current tree for everywhere the individual patches should
be applied.  For example my scripting when it's paying attention to base
commits will ignore anything that's not in the history of the branch the
tree is targeted at unless I explicitly tell it otherwise.

--AVW3f+5yfb/QrPEv
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmi+xSwACgkQJNaLcl1U
h9AzAQf+LOBfPDuwksbahnKf1GXymtpyeLECFBfMfugmzM8YN746jg30JE5ZRXNd
obXc5nva2BXLfe3FR+H7xWkCZutI7bM3bgZsxvFawqo/VsU4lcHV+wN+CsMKqpCM
pds3x8ycVS+idFkJJaHa6YhOIQXq9wg2iMakdgxPgiTvUcyJlLdIyUeeJDLthxYv
1eopWWDLIy2g/ih3koCuBWnxuqr9LqKzxyWaIfaDNOl6L1ZR/6+jLNCYfgN45yv1
gZtWk4HAm7iMYgTJrswhTy2cAZdYrah68vNoFyExCv3oe8/0VBub5Z4jJ8BeZ5dN
BDHjWkP7L4GxJcg2WJKyOrvXMGhLMg==
=m3M0
-----END PGP SIGNATURE-----

--AVW3f+5yfb/QrPEv--

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17])
	(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 ADAB62D7DE9;
	Mon,  8 Sep 2025 20:11:08 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=198.175.65.17
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757362270; cv=fail; b=Tre57/DEVHTu2N7GkWlY46BZ3crH5HmesBuW/JE11KNHk6SdXPJwPv5jlEix+p/4ckXzQX9eSiO7PNzUUlJYjWj3/NoeOdxsCqweQOi+aS5nSph+rvuMSNsuIM3UU+ix6OskFISPzNApd8VA1huLx6NhT0B4fiZYuIjcXtU9GR4=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757362270; c=relaxed/simple;
	bh=iaq2i3MoYsErlJKfvaEUXZiR2BfdfrndM6PnOrtbcjE=;
	h=From:Date:To:CC:Message-ID:In-Reply-To:References:Subject:
	 Content-Type:MIME-Version; b=egoLkAzUs5tIa7/IIAUvRAS6DAnn4sZXYu1KKKCdWE7GjrLneYunLm1aWgPhRc18Ewke+5Jk0dCmJwvAeOepAdqHZ6IBxFUwGkC362NLTQxwm2mr9C+1/ASCYoi8jhdp5f9QyYhtMK14ZW8+npiIPluFdxQBrXDG6u+Pz1hdErs=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=NHhHmtFZ; arc=fail smtp.client-ip=198.175.65.17
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="NHhHmtFZ"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1757362269; x=1788898269;
  h=from:date:to:cc:message-id:in-reply-to:references:
   subject:content-transfer-encoding:mime-version;
  bh=iaq2i3MoYsErlJKfvaEUXZiR2BfdfrndM6PnOrtbcjE=;
  b=NHhHmtFZUGrSSyDWr1RktUWUS/LOYxBvZ5ZGgaEdjSuI1MeyAE/39zNm
   wXokgRu8poyefmbBJQDbeJViqD8qsVTXIweXVaRiSgsSE5WTXE3XcX9eD
   WH9E2onmODuUCtmCSh6U7VNR0H1Qt2u+F7OLuX5iKSdGaLzDZlCn9rRK8
   reP/CkKyhE0iGmTTtqmznsEGG62T6ma3rpqOo+yNQqQxrztmCldW+c22e
   7VTAuRgCD4Hcqrzl0b0ZdgmasdvpYf12CsnApblLr4bgAtv3zXX+YPAys
   z8Ab5+qXSdmWfEy4oVguhZ0hWHag6KyJ2+mlLlC9T3+ux1e5/5rGfiz4+
   Q==;
X-CSE-ConnectionGUID: XVwvyhGtSkGRsLpNQZr8oQ==
X-CSE-MsgGUID: EjXarNhDTOyDWM7znTKA7A==
X-IronPort-AV: E=McAfee;i="6800,10657,11531"; a="59583893"
X-IronPort-AV: E=Sophos;i="6.17,312,1747724400"; 
   d="scan'208";a="59583893"
Received: from orviesa010.jf.intel.com ([10.64.159.150])
  by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Sep 2025 13:11:08 -0700
X-CSE-ConnectionGUID: 8Cn1lABGTYSmGFxykDf4gg==
X-CSE-MsgGUID: RAumEZlKSyaICprsmyopZw==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.18,249,1751266800"; 
   d="scan'208";a="172146817"
Received: from fmsmsx901.amr.corp.intel.com ([10.18.126.90])
  by orviesa010.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Sep 2025 13:11:08 -0700
Received: from FMSMSX901.amr.corp.intel.com (10.18.126.90) by
 fmsmsx901.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Mon, 8 Sep 2025 13:11:07 -0700
Received: from fmsedg902.ED.cps.intel.com (10.1.192.144) by
 FMSMSX901.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17 via Frontend Transport; Mon, 8 Sep 2025 13:11:07 -0700
Received: from NAM02-BN1-obe.outbound.protection.outlook.com (40.107.212.40)
 by edgegateway.intel.com (192.55.55.82) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Mon, 8 Sep 2025 13:11:06 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=NV4JsTTK5L6Nd5qhEcjM1Ncxaw0JoYM9P4jA8laK18MOw0uDMNe76Vf840RBU20I3H1m1haHz/UosqWt0v6YzCT37BqtWhVE27y1GFa4CuoWnm4SW/XDS5H1NzT9NF8UhJST5p5Ix9kWz0M8wVI9EUPGc8tp24CAzUe5KPPIjt1C7RvMHuz8kWso5sZT4I0e8WC+uw2kA/BHYoAlP2MOkM71icb+DuvTteS0lSGGHMDwrROPPqkml6OPjtTYTpILL0j7YXZKAocjCv5Yxqyw8ZBVH47k8yvm5G3uJh4nfrKPcDNTOG95xxIdte6mV3q5/KfkdWrA+U5HCD/OIAW81g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=guZE03T+pem0HKh0keWyPqsThox95SRtoRWE5I+nmPs=;
 b=av6rzgmdg5hYqL9OOnxRiZ5pBEtlCmqxtUjwKPeLspvONRtzbYigYT2MIfQmkoKoYFyMyzY/pDMBafeHKwR96hyO1jEd84Ji1RyHGxne8NsRQhSG2USYsL83Rzvlcjd8Y43IOGOyRzrGnnvMM+YQGKrrf60ZslmOY0C613kTTDsLazulaZzjdk0ge/pfZRmP6UJvBWzvAceH6uPqy4kRirSN/HYq73Tojg/RJBo8cImopsDdQqkkH7fg2zGnDXGAIHyeROD/0lxDdX8LQ/ZuQVL6okji8HHcBKl1bGXZAfFf0YYuAVJwKUFHgYRLklTRJAicc2gdA68YmUHXtpayJQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;
 dkim=pass header.d=intel.com; arc=none
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=intel.com;
Received: from SA3PR11MB8118.namprd11.prod.outlook.com (2603:10b6:806:2f1::13)
 by DS0PR11MB7359.namprd11.prod.outlook.com (2603:10b6:8:134::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Mon, 8 Sep
 2025 20:11:04 +0000
Received: from SA3PR11MB8118.namprd11.prod.outlook.com
 ([fe80::c4e2:f07:bdaa:21ec]) by SA3PR11MB8118.namprd11.prod.outlook.com
 ([fe80::c4e2:f07:bdaa:21ec%4]) with mapi id 15.20.9094.018; Mon, 8 Sep 2025
 20:11:04 +0000
From: <dan.j.williams@intel.com>
Date: Mon, 8 Sep 2025 13:11:00 -0700
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>, Linus Torvalds
	<torvalds@linux-foundation.org>
CC: Jens Axboe <axboe@kernel.dk>, Caleb Sander Mateos
	<csander@purestorage.com>, io-uring <io-uring@vger.kernel.org>,
	<workflows@vger.kernel.org>
Message-ID: <68bf3854f101b_4224d100d7@dwillia2-mobl4.notmuch>
In-Reply-To: <20250905-sparkling-stalwart-galago-8a87e0@lemur>
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
 <20250905-lovely-prehistoric-goldfish-04e1c3@lemur>
 <CAHk-=wg30HTF+zWrh7xP1yFRsRQW-ptiJ+U4+ABHpJORQw=Mug@mail.gmail.com>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur>
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: BL1PR13CA0262.namprd13.prod.outlook.com
 (2603:10b6:208:2ba::27) To SA3PR11MB8118.namprd11.prod.outlook.com
 (2603:10b6:806:2f1::13)
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA3PR11MB8118:EE_|DS0PR11MB7359:EE_
X-MS-Office365-Filtering-Correlation-Id: 5cbe5f91-20c5-4b61-df2d-08ddef13d678
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007;
X-Microsoft-Antispam-Message-Info: =?utf-8?B?bXY2QUh3WVBrZDVYUWpZNFE5L3V2QndTTnpzeUZKZmN4S0ZLYnJ0WHJDUTNR?=
 =?utf-8?B?SjlDU0l2dmJ3VmNoWFlpdjFLQnBjbGFoRzU4R0c4TWNmRUdFZjQrTkF0Zm4w?=
 =?utf-8?B?VEdYY1FoaG80RS9yNmk2Nlk1V013MnU1NldEWXNuR3d6enlDOFFobDFrYkdl?=
 =?utf-8?B?N3E3dkFIVVZDdzYyRzVKajVwL3V4SUhabHRRTldxVmR1T2xrVXB5ZWdkclF5?=
 =?utf-8?B?REFlZEVOQ0lhaEFwSEFjYS9mQVlKUXMwYlNZQWowenBzQjdFMlphT0FtQXBV?=
 =?utf-8?B?RjNpYWNVZ0Vta0VoWnE5V0lnY0xhT1BhZUE0MTlkdTc1RXZCTDRlMDM0YU9j?=
 =?utf-8?B?OTFmWjkvck9BVk0wZ1Vzd04wdU5zSjg0elZmUFp3SFlqUjRjR0dVTXNhcUR3?=
 =?utf-8?B?UWltMnpaeHBuLzdOanExVCtaT2pwd1pHTjI5aTBCOHlhdFh4MGZnd3RJLzZ0?=
 =?utf-8?B?YjgzcjFHaEM4ZXQwd1Jpb2lZbjk2OTI1YjZaUnBLL0hiVjl5Q01EeFEvYUpE?=
 =?utf-8?B?dEtTWWVPb2VVWTlYOUVFWHN4K2dhNGZheVhjRWN2UXVPaHdycDFpdk0yU2Zx?=
 =?utf-8?B?aXViYWJkcW0yQXNHMyszT2xDM3dEWnZMbVhONHh0c1VXdHZ1ZHpwUm04R0la?=
 =?utf-8?B?NnZGL1A2TkZ2M2VJMU9RK0R6VEl3V1V3eUxoNWl0eEJvak85d1JkQnVqamRJ?=
 =?utf-8?B?SjZCeGUrNHlXN1Y3Vm5RcUwxbG9Gc2V0OHJnZThKd3ZKNHJqWS9uQkpaWU5J?=
 =?utf-8?B?cDBpbElBZjNYQlg4R2Z4ZG0zT1VHL1laNnpFUXJkei9ILzFJdHg3MzI4aWgz?=
 =?utf-8?B?L05LU0RldDdNaEhld2wyaFArRHRUeTl1RHBxeDFUbHFXbDV1L2dqaEV0UWpJ?=
 =?utf-8?B?cDRKVkQrUFplVEtEbXdFVXJtSy9KK3N4YXNodGVNQ1ZlMXUyUndodml1WGl6?=
 =?utf-8?B?UWdmbktDbTVDYW4xcjVIS0x4bE94MkNqakVCeGhrRTZQTUtPNEJKVlMzbThy?=
 =?utf-8?B?TG9JUnJHY2lyRjVkL1Z5K2FsNmFQZXl5K0g3WG5VWjZ0YkkyU242WENRMEgy?=
 =?utf-8?B?V0NsdFRwUFpnVmFQZElBcDdDMUxmWUx5ZWtHT1VMb2JPRmsvcXlhYnJxSFNv?=
 =?utf-8?B?N05pTXZpVkVoT2lNZisvSnZwTVBGbFZaQjhkOEJjeDdKTFpCRkE1dmd0S01J?=
 =?utf-8?B?ZElFemRQb0hsdnZrOFVoWCtlTUdweE1kSkJJSDU5WWpYb3M0TUN0d050UnpK?=
 =?utf-8?B?ZkplUjVzS1VZZ2VrdGk3U1pEWjZZNVcwUkR6a1BJTmQxcWZGUmsyN2J5S1NH?=
 =?utf-8?B?dHh5am8yd3dNQ3Z6VHA1MXJJenJ5bWRVTTlGelRMWlo0bUZDTWpPZ0x3V1RS?=
 =?utf-8?B?bEZsTlJ5aWdmTG9rQi9TeFpkbjdSWlFmWlpweEtpNVMvODVmMHY1d3FFRXlo?=
 =?utf-8?B?RzYxQTNOVkl2WDZVeUNHS0lQRlBqbG94MGZvNENHWUtSK01UTytncmJqVWk1?=
 =?utf-8?B?aHNXR1lUeHVrMTZWdmRDRVdINmF1aE5kcWFpMWJyNDZCRXFWZXJWWk4zYkRX?=
 =?utf-8?B?SVJMY2RvelpobEdmWUd1MFhYTWp4TlV2clU2K3h2NXJzeDBoMkRSVGk2aWdB?=
 =?utf-8?B?U3VpY21DTjhSVmtJaXBWVTkzU0RMekZidXZxQ28yeU03UjA4VXc3R3BVUVk3?=
 =?utf-8?B?RU0yWEtUT3UrWFFWSkFhZHVMWnQxeFZtOFE5cEU4bkRndnRpOGJRNThITjht?=
 =?utf-8?B?OC9BZ3dxZnk2bG5GNVVCMmJsM2h6U3V0cndGMnBJd1hnTDRDaVhNMjhZdVhn?=
 =?utf-8?B?OFN6QU5EejRnbktsTTVjV3Npc1M4UnZXQkw4clVjd2pOeWh5ajN5RS9haTg5?=
 =?utf-8?B?QWZoMk1hUTNONE1uUittYzZnOHNLaWRRTllqd1lRYk96dVdEVEVNOW96bU9E?=
 =?utf-8?Q?CXw7bTR9Xds=3D?=
X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA3PR11MB8118.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OTVsKy8rMDVXRGNpMElhVHZ2YnhVTlZ2OXoxZW1VbFR0K0R3NG9ET3cydjlO?=
 =?utf-8?B?dWk5U0lmenRndXN6MlI5WnQyTlFuN01wU1lDQ1NlOWxBbnN2THRVRnYwR1Mx?=
 =?utf-8?B?VTY3MnNRQ0RaTlEzd2pnS3o3UnpCRnErUHhHNVU2MHFhSEFnMnBCcVUzUUM0?=
 =?utf-8?B?ejk1SENrUHRKRHlycUNweVFNWCtsdnBkbTBsRFJ1RGVtN0l2OXh4MGFMQzVn?=
 =?utf-8?B?a0FpQ0kzMWhSWGV4MmlCcWlaeUh5MENZcWhUOENObFRHMzMvanVadjVCWXpL?=
 =?utf-8?B?QXFQWnR3MHZBdE5NTk9pRUZFWHRBRXp1QXd3bisxd0hpeEpaOG9MWXl6ZEpz?=
 =?utf-8?B?ME9JSktjWEtxTXlPQVgybGswc3J5UVM1MHJmcTVkZDUxT3hXOTN0MXpHYXZs?=
 =?utf-8?B?bU9vMWwvTVRxV0pxdlZ0RnJ0Rlp5L0huQU5CdmZIMU1tYnFnNktwakdzOExM?=
 =?utf-8?B?MzZDMldDa25YRGpveWZ4RWdpRXdXWFpPNFNZRVNEMFZ2TmxCTTZVYWh5ck9M?=
 =?utf-8?B?UXh4S2ZlVndmTUxxYTU4OWFOTUE4WWpXY2NFSjZ5VjlmZzlPU0trV21qaGpL?=
 =?utf-8?B?bko5Y0lyd3FmRWNRWkpZVUN2eGVOakVObWYvczFRaUE0SEJTcC9nbnlsaWhB?=
 =?utf-8?B?ZmYyTkJwbCtYVmlYbXpMYzlTeW9KT1l4SERyZUl3Q0xoTzRocXdHTElqNVRu?=
 =?utf-8?B?empmcTFiM2dJdkQ0bUNnbGpQT3crbU9LUHRTS0NUNW1Vazg4MEx1MlFYa1c5?=
 =?utf-8?B?YjBYMFFmUDV6Z3dkOThlbUhIcXRMRTdOZXhGaEhFb00ybjVDTGw2SEIxWWpS?=
 =?utf-8?B?OFJ4Q0tPM2RveXBzOE9VVzVQVDVCZVBWZDM3VW82YW01TGJRZW9weW03RmZ1?=
 =?utf-8?B?K1lxNjRZWWwvTEdkYmY3LzVmSDJZMHI3R2gvUmthNjlmQU1BUjVKN0lGcmV2?=
 =?utf-8?B?aDZkVER3aWZxeVA3TStOVUpWa0dCcjMvYTQyaFBKb0hRdlBtVFgycGJJeExu?=
 =?utf-8?B?QmtJYTBVL1BZVFBueGdmRDViWk9rR3VjYndvVzhGcWlCUVcvNkl4ZmlnOVdJ?=
 =?utf-8?B?VFh3dWR3WVQ1d0JWOGEzbHFnd0ZxZlJwRFA3MWpHUmk2eldyMkZkR054TXdo?=
 =?utf-8?B?VkdSNWFoQUdXWmk5dk90T0RrNTRpTm1EMzl3NzRoa3pxdTNTNUI2ZVlyTmtp?=
 =?utf-8?B?clQyQXJXU0ZVZ0lsUHc4Ry9nMWFpa3dRK2RLeFNYbTdwMmJicUkzT2ZBTzNw?=
 =?utf-8?B?RXUzRlZIdVVHOURoa1MzT3dkTkJQQTkrV1Yvb0JBMXRtb2JxamQ3UnJxN3kv?=
 =?utf-8?B?Qk5oME9nb1U5dGJkOU5UbVQ0SXN4Mk14Qmt6YWhCVFRHTkhxN0tTdW9CcDBy?=
 =?utf-8?B?TmRaay9ybzBscU1jcGpQYTl1bW5MRzdvbTlLUVdQMWh3NmFOU09ERFNTS1c0?=
 =?utf-8?B?TjJEcHFnVzhwSktMS1FCUkhaK0ZRa1VRaG15MmQyL0dwN1FKakFqTTgzVlF5?=
 =?utf-8?B?YUJEQWJoK1o1MVZVRWJGblhRN01obTdxTENwTWNkQnlRSEtNTHRZZGduYkgw?=
 =?utf-8?B?Y2xDZnlWcUwwcDhFRTVSZkVxNEJ1VFJ3dGNkK3lFRWFoUU1laUVET3lNNVE1?=
 =?utf-8?B?b2x5cTVDcjc3YmxKSjBnTFNDL2xWb2ZaQUh1d0liWnByRERqakZwTmQ0M2Iw?=
 =?utf-8?B?UDNCdjB0L1F4dm9uV0JPQVl3cFkyNmxYTDMvWjA2L3FYcXJqY1ZZVHBoRTdF?=
 =?utf-8?B?NHhQZGpNV0hoN1NHOXViU3pNbktSSldXUmpvNVJqb3lFWEYzUG1CY0p1b1Vx?=
 =?utf-8?B?VXM5Z0JXVTJGWTlUT09UZHBLOEowODVPenVGVTNhKzZHOGFhUXRCNXUyWlhl?=
 =?utf-8?B?MUhlenpVZHltUHdTUTBhSkhvL09YQklEUXRFcmxzanZBdGlpRE5ETmxGWHJZ?=
 =?utf-8?B?YmtROStLQS9KeUlPSWsvek1yeEVqR1ZYa0p5VGpjL0lLYzRlSUxrOUFkQTFo?=
 =?utf-8?B?OUpxS2ZrS3lHSFl5Z2E2TlhnZENJZ0Fqbm5GcUIxcFBUeGtXQUFXQWxFaGRQ?=
 =?utf-8?B?M2l6SmNOZVZ0QUk2bEt2eXIvTmxzRmtlc1ZHay90S0FPL3VvM3ZvcXRRamRG?=
 =?utf-8?B?SlExcEE3eG1iZzNqeG9GdXJIQnFrMGU0N3BaRDI5T3NaRHNTUzE3NVRMVEFr?=
 =?utf-8?B?T1E9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 5cbe5f91-20c5-4b61-df2d-08ddef13d678
X-MS-Exchange-CrossTenant-AuthSource: SA3PR11MB8118.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Sep 2025 20:11:04.0257
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ZqtTu97M9jQBSSx8xXFmymbRNSqmbVM6bFhn/wKf1BUNvnJ/vohGPVYHYBQRfPvZOakHfEXY+PEURLjcfWzODry9LcixVZkePjyHyc2SD/U=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR11MB7359
X-OriginatorOrg: intel.com

Konstantin Ryabitsev wrote:
> (Changing the subject and aiming this at workflows.)
> 
> On Fri, Sep 05, 2025 at 11:06:01AM -0700, Linus Torvalds wrote:
> > On Fri, 5 Sept 2025 at 10:45, Konstantin Ryabitsev
> > <konstantin@linuxfoundation.org> wrote:
> > >
> > > Do you just want this to become a no-op, or will it be better if it's used
> > > only with the patch.msgid.link domain namespace to clearly indicate that it's
> > > just a provenance link?
> > 
> > So I wish it at least had some way to discourage the normal mindless
> > use - and in a perfect world that there was some more useful model for
> > adding links automatically.
> > 
> > For example, I feel like for the cover letter of a multi-commit
> > series, the link to the patch series submission is potentially more
> > useful - and likely much less annoying - because it would go into the
> > merge message, not individual commits.
> 
> We do support this usage using `b4 shazam -M` -- it's the functional
> equivalent of applying a pull request and will use the cover letter contents
> as the initial source of the merge commit message. I do encourage people to
> use this more than just a linear `git am` for series, for a number of reasons:

For me, as a subsystem downstream person the 'mindless' patch.msgid.link
saves me time when I need to report a regression, or validate which
version of a patch was pulled from a list when curating a long-running
topic in a staging tree. I do make sure to put actual discussion
references outside the patch.msgid.link namespace and hope that others
continue to use this helpful breadcrumb.

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 5407531D741;
	Tue,  9 Sep 2025 11:29:16 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757417356; cv=none; b=vAM9Q6rxTwMmSrjK/up4bwaVkt8fqqtrOi7GdeAtcu9wY0xB+v+2I7z2GxZAokQdIx4ET/dkWnDZPajXMj7EFqu0z9ZuRNeIl3MyqxmHfcHL5bKXIPjuSwZcp7epsm5N+LBi0/iqfnogcuRByJvRcZcz2dMKdFJCAgs994D5AXo=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757417356; c=relaxed/simple;
	bh=X0VC08lbTf4ADXXSPh4wvl08HHb0OF1/HAxWNsHKADk=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=k5N5Z5PVfsZtkdRzngnPCG17NokzEmyjaBc5JtFAnzIUB3hRB2cNiYYxHOMSJm/5w1Kox7dsHu2/yd9nnbtNUq8g9D3DG+FguK5xnXzX3kpBSxnInUVDICfdj68wFjLaQTNXDHyLBO/wou8rlRta1NWOmyKK3lcQdRWByNZhkP0=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Cak3ijy4; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Cak3ijy4"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id BDEF9C4CEF4;
	Tue,  9 Sep 2025 11:29:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757417356;
	bh=X0VC08lbTf4ADXXSPh4wvl08HHb0OF1/HAxWNsHKADk=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=Cak3ijy4AfW3KPyos+wo6/CNjzjgeLFY2Rg/gU2LPtfkBhcqIWW5X9BG+Hl6+WBny
	 DAsS91PRHPmvlzCjd4m50Dpj9AyXfA7la8fZVx9zNpFtIuKsqWu2UqwrBRg/BCFQ25
	 l/MiCXpthM9NSgHowDApcmR/Q9b3uUjScp4Bc40HRS+mdc9TW26oKWFm98HLzfkeVm
	 tY1AaO+7tL9TRHQbwQ71oV6TR6JT5DRyR2iSfmqj6aV3rGx+5kVk48bXIDORGUpJv3
	 Qiqcv8vaJ92c/aJRiAVZLM2HC8eh5QcuGZsGIIjIqKhjU4OK4Yh3oHxeKrkv+nJxO4
	 W+RKyaTRQucOQ==
Date: Tue, 9 Sep 2025 12:29:12 +0100
From: Mark Brown <broonie@kernel.org>
To: dan.j.williams@intel.com
Cc: Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>,
	Caleb Sander Mateos <csander@purestorage.com>,
	io-uring <io-uring@vger.kernel.org>, workflows@vger.kernel.org
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
Message-ID: <e448d26b-6514-400c-86ec-29f0f04634af@sirena.org.uk>
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <CAHk-=wjamixjqNwrr4+UEAwitMOd6Y8-_9p4oUZdcjrv7fsayQ@mail.gmail.com>
 <20250905-lovely-prehistoric-goldfish-04e1c3@lemur>
 <CAHk-=wg30HTF+zWrh7xP1yFRsRQW-ptiJ+U4+ABHpJORQw=Mug@mail.gmail.com>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <68bf3854f101b_4224d100d7@dwillia2-mobl4.notmuch>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="iKDciDXwQYc+Lf9P"
Content-Disposition: inline
In-Reply-To: <68bf3854f101b_4224d100d7@dwillia2-mobl4.notmuch>
X-Cookie: Ma Bell is a mean mother!


--iKDciDXwQYc+Lf9P
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Sep 08, 2025 at 01:11:00PM -0700, dan.j.williams@intel.com wrote:
> Konstantin Ryabitsev wrote:

> > We do support this usage using `b4 shazam -M` -- it's the functional
> > equivalent of applying a pull request and will use the cover letter contents
> > as the initial source of the merge commit message. I do encourage people to
> > use this more than just a linear `git am` for series, for a number of reasons:

> For me, as a subsystem downstream person the 'mindless' patch.msgid.link
> saves me time when I need to report a regression, or validate which
> version of a patch was pulled from a list when curating a long-running
> topic in a staging tree. I do make sure to put actual discussion
> references outside the patch.msgid.link namespace and hope that others
> continue to use this helpful breadcrumb.

Yes, I use the links constantly too when reporting regressions - it's
super helpful to just be able to pull the message and thread from the
mailing list with b4.  You get an initial way into the discussion (and
any reports someone else made) and a good list of people to CC.

--iKDciDXwQYc+Lf9P
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmjAD4cACgkQJNaLcl1U
h9D4Owf/QKLfJlZTYPlyLO7+UtV3jD9ccqM8crHbkfIvGdY2MoZJhellCXqHch1a
UjcaHRSOKS9qafOufL8dwRvnofwafAk2oDq5QQc7gOCC47WrXGOlN8Ym3nOtGgUW
mOwuWPSBo6Dncf/kizDH53Xv0UnRhYeXTIoFvwBPUZVTmeqNsBqLDbIh4X79KVVi
CaiAwlfnFdBxdznKG/o7DygTRGbqsi/oV1/9qqnqSDjY69ilf8B9Eo+C2uefb61l
PhJ1hAJcTgyZP/CS/w58xWl3eOao1cvpcoXr4MWEN7CqB4iokXd8AsUGlnqsNIjr
wh504P9YBHYcfacAYAIqQevv3kx2NA==
=14Or
-----END PGP SIGNATURE-----

--iKDciDXwQYc+Lf9P--

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 5FA5A21B9F6;
	Tue,  9 Sep 2025 13:17:21 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757423842; cv=none; b=sDh86awGtBctHFGGo2I/1nLRhOVMci1EOvOLtP9qozKsb1xQi2TmsoJ/Zj1ViJbSDOUG+lrEzUUcAcjNM7d/zX8RQwglcHJC6xPCf1h6Mt+lzeuHLWDnkYnO5YJ9Z07KXf/oOPOvW6eFhhhLXcfY8/EjtWGw2++eipI0Pr9tSCE=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757423842; c=relaxed/simple;
	bh=hRxld0LQgbxPOlzudrdWuevDjVRV7o89tn8SOw9Mu7g=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version:Content-Type; b=k8aIpdmWjKuIu81Izu1H02RpfMkGq15TLeOr8pwMg//RzSDBbgACITsfMgtQe5MqKWoVJGXddkQhAt7sIpncNPv44ueSdZz8w1VPK9/kk0BdQfEHUYiJBKGk6K2nf5oPznjsd5vkA6jOZWGSUfNOspHV6lJXtEKtwgeDk+mv5dg=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=c1L1RwJC; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="c1L1RwJC"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id CDF42C4CEF4;
	Tue,  9 Sep 2025 13:17:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757423840;
	bh=hRxld0LQgbxPOlzudrdWuevDjVRV7o89tn8SOw9Mu7g=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=c1L1RwJCw9YLWyfXu0dgC8lxdvgHmQCMs0JewlmU3hj2DaLCUqN0q1FKoTI/bM2GQ
	 TVWA+rmVdWFRCii+Ymul3fHAowoE+GgSD4owH759ghy4Ou8jfrcFTbBK4k+BZlhFMI
	 r9XN9ODtSSM1Kp0v5A5I1wLtT4lOkC9HesOTe+3P6Yadi9W37rs5jzqACeZtS9sbYp
	 a8mzd4KhMhuV3OcteN2gBIWySU+52UAPtrVeXfvca19eflqAN56c6XFVmPveH89M/J
	 C9pd6RCQnKgsbzduwA+lXTOG0gvHSal494AjgRSehDDAcpz/VxuRCe7Dok+JDPdrmn
	 6GkmwamawT+fQ==
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
 Linus Torvalds <torvalds@linux-foundation.org>, dan.j.williams@intel.com
Cc: Jens Axboe <axboe@kernel.dk>,
 Caleb Sander Mateos <csander@purestorage.com>,
 io-uring <io-uring@vger.kernel.org>, workflows@vger.kernel.org
Subject:
 Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for 6.17-rc5)
Date: Tue, 09 Sep 2025 15:17:15 +0200
Message-ID: <5922560.DvuYhMxLoT@rafael.j.wysocki>
Organization: Linux Kernel Development
In-Reply-To: <68bf3854f101b_4224d100d7@dwillia2-mobl4.notmuch>
References:
 <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <68bf3854f101b_4224d100d7@dwillia2-mobl4.notmuch>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="UTF-8"

On Monday, September 8, 2025 10:11:00 PM CEST dan.j.williams@intel.com wrote:
> Konstantin Ryabitsev wrote:
> > (Changing the subject and aiming this at workflows.)
> > 
> > On Fri, Sep 05, 2025 at 11:06:01AM -0700, Linus Torvalds wrote:
> > > On Fri, 5 Sept 2025 at 10:45, Konstantin Ryabitsev
> > > <konstantin@linuxfoundation.org> wrote:
> > > >
> > > > Do you just want this to become a no-op, or will it be better if it's used
> > > > only with the patch.msgid.link domain namespace to clearly indicate that it's
> > > > just a provenance link?
> > > 
> > > So I wish it at least had some way to discourage the normal mindless
> > > use - and in a perfect world that there was some more useful model for
> > > adding links automatically.
> > > 
> > > For example, I feel like for the cover letter of a multi-commit
> > > series, the link to the patch series submission is potentially more
> > > useful - and likely much less annoying - because it would go into the
> > > merge message, not individual commits.
> > 
> > We do support this usage using `b4 shazam -M` -- it's the functional
> > equivalent of applying a pull request and will use the cover letter contents
> > as the initial source of the merge commit message. I do encourage people to
> > use this more than just a linear `git am` for series, for a number of reasons:
> 
> For me, as a subsystem downstream person the 'mindless' patch.msgid.link
> saves me time when I need to report a regression, or validate which
> version of a patch was pulled from a list when curating a long-running
> topic in a staging tree. I do make sure to put actual discussion
> references outside the patch.msgid.link namespace and hope that others
> continue to use this helpful breadcrumb.

Same here.

Every time one needs to connect a git commit with a patch that it has come from,
the presence of patch.msgid.link saves a search of a mailing list archive (if
all goes well, or more searches otherwise).

On a global scale, that's quite a number of saved mailing list archive searches.

Cheers, Rafael




From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 6D89B2EDD52;
	Tue,  9 Sep 2025 14:18:20 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757427500; cv=none; b=uyz01oZZ+w/uIgEvMlb/sD+kAxpuiELYl37k6Oz8qPP8x28IKUvHVwD9RoGxs2//DJ2DrNmilQCKuwlQlFypW0bF5BFRRDDW2Qt92ikRRKlWy+gDDne0U87oOiZfG4CFLGs6PI1SgB0tACFECgggt3rFTaNMoFc/wRph9ip41Hg=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757427500; c=relaxed/simple;
	bh=L3qH5tnuygJ0kC75f4V1VnsxdNy60kwL27d9IJFGMLk=;
	h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:
	 MIME-Version:Content-Type; b=a2lTz8XK0yjJxolx0kkW2rZaobZrsq3HrZMlXQsaG2EGNK2Id7w/jp9EJyOWJZBVfuJSO7ZQYRZyt8AK4Nzl5HMPlQlq4xEGA/AeKobALhGqBXclFmf9nRb6HbK6Xhzrc/hita5b4MbUMK4i7vpNhJySFaPpbl0mb/km8S8uj2s=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ci695d5T; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ci695d5T"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9A690C4CEF4;
	Tue,  9 Sep 2025 14:18:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757427500;
	bh=L3qH5tnuygJ0kC75f4V1VnsxdNy60kwL27d9IJFGMLk=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=ci695d5T5gWqGp7j7eEywyf2j3kP9Sj4VfSVxD6/0CK/aht/zvdHh1sW9mgxHIufY
	 d6lM5AtIjjcQZcUP4lKcBDJtC5qm21avaRs8DOMHNPV85qhtUUVSul+kzXq3aLHkKl
	 6I6GI6cwAzmw/G3mEFKxMcGW/a4ut/i97KjOF4l7YgCxf9GASynV8n3aFbMbgINDeN
	 Edu+QqtGsxAnzDLS8E4shhjPmud9jLNc44US+QCcjlfuDeSxh/onYxdXJGrTKKeNFj
	 zf5dhionb/yEAgwYxKqrJL8EAzhWMvVglhLc4eGrRW67f3qlRioNTNZ4vHMAxRiSQM
	 nf1Qnpm0x+AQA==
Date: Tue, 9 Sep 2025 07:18:18 -0700
From: Jakub Kicinski <kuba@kernel.org>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>, Linus Torvalds
 <torvalds@linux-foundation.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>, dan.j.williams@intel.com, Jens
 Axboe <axboe@kernel.dk>, Caleb Sander Mateos <csander@purestorage.com>,
 io-uring <io-uring@vger.kernel.org>, workflows@vger.kernel.org
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
Message-ID: <20250909071818.15507ee6@kernel.org>
In-Reply-To: <5922560.DvuYhMxLoT@rafael.j.wysocki>
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
	<20250905-sparkling-stalwart-galago-8a87e0@lemur>
	<68bf3854f101b_4224d100d7@dwillia2-mobl4.notmuch>
	<5922560.DvuYhMxLoT@rafael.j.wysocki>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 09 Sep 2025 15:17:15 +0200 Rafael J. Wysocki wrote:
> > > We do support this usage using `b4 shazam -M` -- it's the functional
> > > equivalent of applying a pull request and will use the cover letter contents
> > > as the initial source of the merge commit message. I do encourage people to
> > > use this more than just a linear `git am` for series, for a number of reasons:  
> > 
> > For me, as a subsystem downstream person the 'mindless' patch.msgid.link
> > saves me time when I need to report a regression, or validate which
> > version of a patch was pulled from a list when curating a long-running
> > topic in a staging tree. I do make sure to put actual discussion
> > references outside the patch.msgid.link namespace and hope that others
> > continue to use this helpful breadcrumb.  
> 
> Same here.
> 
> Every time one needs to connect a git commit with a patch that it has come from,
> the presence of patch.msgid.link saves a search of a mailing list archive (if
> all goes well, or more searches otherwise).
> 
> On a global scale, that's quite a number of saved mailing list archive searches.

+1 FWIW. I also started slapping the links on all patches in a series,
even if we apply with a merge commit. I don't know of a good way with
git to "get to the first parent merge" so scanning the history to find
the link in the cover letter was annoying me :(

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7D1B0350842
	for <io-uring@vger.kernel.org>; Tue,  9 Sep 2025 14:35:20 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.166.54
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757428522; cv=none; b=dm19OGBEI5nS7130gQ5qa2FEIHfGlEGaMAlAyVBAatSlfJtuQPdmUTr+jYwF2RUz+kNPJ1+h2ujUhppTYv0ov0/U96q3UUuyObVN55E+yqhUBraccVjpkWvObSL9B/C1b5CLmUwEo58rLzPI0l9n3H/4VeiVH/CdN6/sc7W/rqk=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757428522; c=relaxed/simple;
	bh=rQWH/NmcpNFnxB0wgun6+QVk7GxdIWJElTzM6KFhoAU=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=EOAHxmeuibkBOF9qWXFUZJii/HpW7zmjmfBo263V/zsYArQLONjg5Kx21enmk2nJx7lywywhFt68n1qh0V3MhWC8DKK6ABfwEOCCRqn/aMTdTfz2qiqmoNh6rRsZ5vfBSQSTo8z3Q5P6MQecf6xUyJoOepnLAM5oLzBHRzVewmk=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk; spf=pass smtp.mailfrom=kernel.dk; dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b=0GDAS6Os; arc=none smtp.client-ip=209.85.166.54
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kernel.dk
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b="0GDAS6Os"
Received: by mail-io1-f54.google.com with SMTP id ca18e2360f4ac-88432a1ed9aso70038639f.1
        for <io-uring@vger.kernel.org>; Tue, 09 Sep 2025 07:35:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=kernel-dk.20230601.gappssmtp.com; s=20230601; t=1757428519; x=1758033319; darn=vger.kernel.org;
        h=content-transfer-encoding:in-reply-to:content-language:from
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=EMgUYo9u9E3FopZ0TDjXKfzm0MSZWxygWvWesTcsWZs=;
        b=0GDAS6OslgMQwR5jwQ3TbH4YKD3FhNHwec9oXQTsDYXUen/wT8zbsVD2LK6oY1c9Tn
         nZzSxSJW5rtZzTjm3tbASNwOhWb1mnC6TDzgRzOBp+9uCwSdo8WcWMrIYB9lzq3h3e+5
         0aVcU4OgW4U9dKSG3EXeigxREg47QnFuR3RxPs35Q58g8CKMHjpApV4SX6CasxQv8hwE
         bNp406qDFrsvlwqD+VL/0z97KEqjayR3fyLww4BYsAbbs28qBcJ+gH1onHs/0S3F7/QL
         dzEaX4n1MSa1ZD7UQMvH1Tspv/fCxDQPOyWHCoch+gX/GXD0BeCeQpvq82ilvV4V+NA6
         rWXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757428519; x=1758033319;
        h=content-transfer-encoding:in-reply-to:content-language:from
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=EMgUYo9u9E3FopZ0TDjXKfzm0MSZWxygWvWesTcsWZs=;
        b=FDkxsrltvMVAERtICMnov+c1KAUpgLeiPNpKP2aQONWNIrm9dzVgEtgMO2xOxX/Z/R
         1Kc1AHB9uZzXGcyr8dxFnM1uh6S4X7Ui22sSjYWREbU7sNWW47+6BOgZmn3o16l6zSl7
         Wjz0HfvR02tt3ozUE6/wQwyy8sXxWCNFqi+Ql6Us6mweMP1K0SS2OQc2C2iY5jBr5kwp
         XHz/lTIDxWpsamI/I4MWYWqp0ROSolbplV0NXLGBWDDcWC1dIQF1grP4ScJ0o2/zvR+e
         T4OCRA0EGrNq6A6pkU9v1bSqAnDCzgYorqc2MudTfYg+b8At9UJn/rLSQq9MNpHu8BO1
         sw/Q==
X-Forwarded-Encrypted: i=1; AJvYcCUPzWFlBhtI03VB+2rjOxyF/j5sJ+HJOxjrJbGmQp6lJnoxiESxRYklPzyerfFlhZPNOFF2l16Hwg==@vger.kernel.org
X-Gm-Message-State: AOJu0Yz7l/yZ5oAlLdBgLWFzxssezwrn3wh7kHCnF5tg8S4qvs7ZTp4E
	GTR35ZFfRBaV39d2OnnnxArdCkanPxXax5y0JrtUrQydDet8ejIdqGITmWDItbqLNfI=
X-Gm-Gg: ASbGnct92RCMqBNZ4NGUhvBC6Wt7LjC0XME73QN5u0lwPKhXiKl5XjqSyvQ9BOuVwyz
	eo9wdpK1Go+DsSOqUJWsH3dHnSu8FjXIiSr/vFWRJEgssQuMOIJaDSMm2TwFVOqXa2EfEdINZjs
	D48hpU4AnnSruBXxOeY6HS2vAPS3XHe7UaLK/k6MA8Hbg96M1kD7JSNSnBKT1YvpyqMM7yhYsXD
	dZY41LhWe7XHyoVMCgrduJbH0wxwT4QXaIUBZP1jDQUzIG+D6tpkbP17XVE14+Adehgj9mXvB42
	pR+/6X+c61R5SmWuk28FEtboGAQETlsHVR03z2OJpbxGHktTd/B0MppQEyg0JI8rw0eSw9E4Zgp
	zqVzhQASaEGQNXGLKUSY=
X-Google-Smtp-Source: AGHT+IHaannFzQXhK7EjrWWeA0pcTCulS9Fd5iidHKoVs+Dzgs/KTqYZPXCTQxNYHuxa2UK2dtfBrg==
X-Received: by 2002:a05:6602:3fd4:b0:883:fc4a:ea55 with SMTP id ca18e2360f4ac-88777999fdcmr1890133939f.3.1757428519370;
        Tue, 09 Sep 2025 07:35:19 -0700 (PDT)
Received: from [192.168.1.116] ([96.43.243.2])
        by smtp.gmail.com with ESMTPSA id ca18e2360f4ac-887711c4ee5sm408829939f.17.2025.09.09.07.35.18
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Tue, 09 Sep 2025 07:35:18 -0700 (PDT)
Message-ID: <92dc8570-84a2-4015-9c7a-6e7da784869a@kernel.dk>
Date: Tue, 9 Sep 2025 08:35:18 -0600
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
To: Jakub Kicinski <kuba@kernel.org>,
 Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
 Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>, dan.j.williams@intel.com,
 Caleb Sander Mateos <csander@purestorage.com>,
 io-uring <io-uring@vger.kernel.org>, workflows@vger.kernel.org
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <68bf3854f101b_4224d100d7@dwillia2-mobl4.notmuch>
 <5922560.DvuYhMxLoT@rafael.j.wysocki> <20250909071818.15507ee6@kernel.org>
From: Jens Axboe <axboe@kernel.dk>
Content-Language: en-US
In-Reply-To: <20250909071818.15507ee6@kernel.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 9/9/25 8:18 AM, Jakub Kicinski wrote:
> On Tue, 09 Sep 2025 15:17:15 +0200 Rafael J. Wysocki wrote:
>>>> We do support this usage using `b4 shazam -M` -- it's the functional
>>>> equivalent of applying a pull request and will use the cover letter contents
>>>> as the initial source of the merge commit message. I do encourage people to
>>>> use this more than just a linear `git am` for series, for a number of reasons:  
>>>
>>> For me, as a subsystem downstream person the 'mindless' patch.msgid.link
>>> saves me time when I need to report a regression, or validate which
>>> version of a patch was pulled from a list when curating a long-running
>>> topic in a staging tree. I do make sure to put actual discussion
>>> references outside the patch.msgid.link namespace and hope that others
>>> continue to use this helpful breadcrumb.  
>>
>> Same here.
>>
>> Every time one needs to connect a git commit with a patch that it has come from,
>> the presence of patch.msgid.link saves a search of a mailing list archive (if
>> all goes well, or more searches otherwise).
>>
>> On a global scale, that's quite a number of saved mailing list archive searches.
> 
> +1 FWIW. I also started slapping the links on all patches in a series,
> even if we apply with a merge commit. I don't know of a good way with
> git to "get to the first parent merge" so scanning the history to find
> the link in the cover letter was annoying me :(

Like I've tried to argue, I find them useful too. But after this whole
mess of a thread, I killed -l from my scripts. I do think it's a mistake
and it seems like the only reason to remove them is that Linus expects
to find something at the end of the link rainbow and is often
disappointed, and that annoys him enough to rant about it.

I know some folks downstream of me on the io_uring side find them useful
too, because they've asked me several times to please remember to ensure
my own self-applied patches have the link as well. For those, I tend to
pick or add them locally rather than use b4 for it, which is why they've
never had links.

As far as I can tell, only two things have been established here:

1) Linus hates the Link tags, except if they have extra information
2) Lots of other folks find them useful

and hence we're at a solid deadlock here.

-- 
Jens Axboe

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 E62A71F0E2E;
	Tue,  9 Sep 2025 14:42:45 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757428966; cv=none; b=eP8+2ZpeVYRJE0pW2HmlgzvtG4ROV4AnOx8yTh2zVuB4OCl/0b+mZ+GaT35yr8F1yiAq+/jwNPjGYi3TZe5ju3MUbebt7Wcib1quQiqs8fcJnWTQKI+UFLpSPY7MaqG8CCsvAqca25s/2UI78OgylyvaYkyjQVx9KH2i6qhJzk4=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757428966; c=relaxed/simple;
	bh=yswqqtHRFfmdynkmFeRMH6eFXkkhcbu28VuZarxyqig=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=PNVd9A9WfgDfPRRyPnhNRXNhnRm/JqApWgJsbS+ltpDvMYC8lv9OndhC0ZcSOwEfFQyMQvU3xmY/jGX10ABw41TaNPvuzOyulPQwUu4/z+Vh62KS2dmNvOsHX+lpL/NytN7HbvNDz3LPYqwYW1o3TbzmDdgqNLQxCTZVZnbwiTY=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=K15USek9; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="K15USek9"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 31B9FC4CEF4;
	Tue,  9 Sep 2025 14:42:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1757428965;
	bh=yswqqtHRFfmdynkmFeRMH6eFXkkhcbu28VuZarxyqig=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=K15USek9aU4bh3Rmt2buh0AJob5KQKmVZL8x8O1lsuXtPurGEfUpDs646xg3lR+Vu
	 kbJwMwRTnwysF0WqSij1djhctIIygYGnfNu/LftQV8+9FPFJc7cEGIARCi6ovr6uCA
	 hAWa/18TBnCrhpjsTq1FU7mlHFQcfkLchYzvMoH0=
Date: Tue, 9 Sep 2025 10:42:43 -0400
From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: Jens Axboe <axboe@kernel.dk>
Cc: Jakub Kicinski <kuba@kernel.org>, 
	Linus Torvalds <torvalds@linux-foundation.org>, "Rafael J. Wysocki" <rafael@kernel.org>, 
	dan.j.williams@intel.com, Caleb Sander Mateos <csander@purestorage.com>, 
	io-uring <io-uring@vger.kernel.org>, workflows@vger.kernel.org
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
Message-ID: <20250909-green-oriole-of-speed-85cd6d@lemur>
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <68bf3854f101b_4224d100d7@dwillia2-mobl4.notmuch>
 <5922560.DvuYhMxLoT@rafael.j.wysocki>
 <20250909071818.15507ee6@kernel.org>
 <92dc8570-84a2-4015-9c7a-6e7da784869a@kernel.dk>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <92dc8570-84a2-4015-9c7a-6e7da784869a@kernel.dk>

On Tue, Sep 09, 2025 at 08:35:18AM -0600, Jens Axboe wrote:
> >> On a global scale, that's quite a number of saved mailing list archive searches.
> > 
> > +1 FWIW. I also started slapping the links on all patches in a series,
> > even if we apply with a merge commit. I don't know of a good way with
> > git to "get to the first parent merge" so scanning the history to find
> > the link in the cover letter was annoying me :(
> 
> Like I've tried to argue, I find them useful too. But after this whole
> mess of a thread, I killed -l from my scripts. I do think it's a mistake
> and it seems like the only reason to remove them is that Linus expects
> to find something at the end of the link rainbow and is often
> disappointed, and that annoys him enough to rant about it.
> 
> I know some folks downstream of me on the io_uring side find them useful
> too, because they've asked me several times to please remember to ensure
> my own self-applied patches have the link as well. For those, I tend to
> pick or add them locally rather than use b4 for it, which is why they've
> never had links.
> 
> As far as I can tell, only two things have been established here:
> 
> 1) Linus hates the Link tags, except if they have extra information
> 2) Lots of other folks find them useful
> 
> and hence we're at a solid deadlock here.

I did suggest that provenance links use the patch.msgid.link subdomain. This
should clearly mark it as the source of the patch and not any other
discussion. I think this is a reasonable compromise that will only mildly
annoy Linus but let subsystems relying on these links continue to use them.

-K

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 3F92834F47E;
	Tue,  9 Sep 2025 14:44:40 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757429081; cv=none; b=OG4AkdZ47KGGcb4ALsNf5ULwNTZW+pZP3M2lVOCzvzwMz618xrNenSY9aZOuj6BVI6Jeo+II9SGwNutcUrbuB3lUgJ5xQgCbrpj/eLFgjjfIA3Cm6sFKTSveZ3Q4fvhZRck5LxNxg+KXsuHNzKxGgA/nFHJwsaU2IAHvhgjuNj0=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757429081; c=relaxed/simple;
	bh=jTvQDaz2CulFQRyRJegugtxzCVwBwv8NYHmDN0oRc1s=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=UGOax6NIr49A5tZT6/zWUNE20z9jLjDCsdchy6LZXzsVwUZqV5ToHAEpMWoiEda/y2pFeifZITjI7cLzg2uz+8yMPkAucThYpQdjgyNoS4WXLKolL9c+m47aVrlhlW0kzsN+VwTdopA/pdImnWaiaOdrOAbdHW2WugjJSawAgaU=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=Q40uWBRS; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="Q40uWBRS"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0DA50C4CEFB;
	Tue,  9 Sep 2025 14:44:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1757429080;
	bh=jTvQDaz2CulFQRyRJegugtxzCVwBwv8NYHmDN0oRc1s=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=Q40uWBRSC2FYSCiYQuiMBK8kUThiXaOjOVgR9FNFBBSzrSEIeDQgevPzVe+R+rvkq
	 NvlfeIC0o7BXT/XYQKWmqGOpVSg5eoJUQWccPS9sgwsoT6POxQWIrILY94KISuW/Qc
	 n6nZk1W6HKlMv6wTey9srVG9zrCuPGumeQ2bdkcA=
Date: Tue, 9 Sep 2025 16:44:37 +0200
From: Greg KH <gregkh@linuxfoundation.org>
To: Jens Axboe <axboe@kernel.dk>
Cc: Jakub Kicinski <kuba@kernel.org>,
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>, dan.j.williams@intel.com,
	Caleb Sander Mateos <csander@purestorage.com>,
	io-uring <io-uring@vger.kernel.org>, workflows@vger.kernel.org
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
Message-ID: <2025090901-mangle-provable-6248@gregkh>
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <68bf3854f101b_4224d100d7@dwillia2-mobl4.notmuch>
 <5922560.DvuYhMxLoT@rafael.j.wysocki>
 <20250909071818.15507ee6@kernel.org>
 <92dc8570-84a2-4015-9c7a-6e7da784869a@kernel.dk>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <92dc8570-84a2-4015-9c7a-6e7da784869a@kernel.dk>

On Tue, Sep 09, 2025 at 08:35:18AM -0600, Jens Axboe wrote:
> On 9/9/25 8:18 AM, Jakub Kicinski wrote:
> > On Tue, 09 Sep 2025 15:17:15 +0200 Rafael J. Wysocki wrote:
> >>>> We do support this usage using `b4 shazam -M` -- it's the functional
> >>>> equivalent of applying a pull request and will use the cover letter contents
> >>>> as the initial source of the merge commit message. I do encourage people to
> >>>> use this more than just a linear `git am` for series, for a number of reasons:  
> >>>
> >>> For me, as a subsystem downstream person the 'mindless' patch.msgid.link
> >>> saves me time when I need to report a regression, or validate which
> >>> version of a patch was pulled from a list when curating a long-running
> >>> topic in a staging tree. I do make sure to put actual discussion
> >>> references outside the patch.msgid.link namespace and hope that others
> >>> continue to use this helpful breadcrumb.  
> >>
> >> Same here.
> >>
> >> Every time one needs to connect a git commit with a patch that it has come from,
> >> the presence of patch.msgid.link saves a search of a mailing list archive (if
> >> all goes well, or more searches otherwise).
> >>
> >> On a global scale, that's quite a number of saved mailing list archive searches.
> > 
> > +1 FWIW. I also started slapping the links on all patches in a series,
> > even if we apply with a merge commit. I don't know of a good way with
> > git to "get to the first parent merge" so scanning the history to find
> > the link in the cover letter was annoying me :(
> 
> Like I've tried to argue, I find them useful too. But after this whole
> mess of a thread, I killed -l from my scripts. I do think it's a mistake
> and it seems like the only reason to remove them is that Linus expects
> to find something at the end of the link rainbow and is often
> disappointed, and that annoys him enough to rant about it.
> 
> I know some folks downstream of me on the io_uring side find them useful
> too, because they've asked me several times to please remember to ensure
> my own self-applied patches have the link as well. For those, I tend to
> pick or add them locally rather than use b4 for it, which is why they've
> never had links.
> 
> As far as I can tell, only two things have been established here:
> 
> 1) Linus hates the Link tags, except if they have extra information
> 2) Lots of other folks find them useful

I too find them useful, especially when doing stable backport work as
it's a link to the thread of multiple commits, so I can see what is, and
is not, tagged for stable, and the proper ordering of the commits.

So I'm going to want to keep leaving them on, they work well for those
that have to spelunk into our git branches all the time.

thanks,

greg k-h

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 998DA352FC7
	for <io-uring@vger.kernel.org>; Tue,  9 Sep 2025 14:48:56 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.135.223.131
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757429338; cv=none; b=pCzTUfW+nOSicCQOJ0HQb0E7xh1aj4QSh/fWiEH96TH0lefCuKBSaivCbm9WPyJ9giCCNr8sB0FicvSXTMVl+eWz7ssRvxstN9Kvld+uHe44hnKnFUvd15lQw44zgRnZqbK4Uou1vZoL4kV+N1ClbNBbadtvzvizd4R9ql6dcQ8=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757429338; c=relaxed/simple;
	bh=8/m1uuK4pT6QflGj2v/a/p0Y3OmL4JI4947k6pbqMCs=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=gsy0tg3YhmebsfrkZh9abyxFXE3ADBl9HoEC6jo5dtZw7tlmbA73kFdojgwpg/08FUCI/06dtk6/Ml2xaHgcLzs3U+FO3pzdHl7bCtoaFf5WaY0GosGX4DmNeb0Qqes9XG9LHBPzZRoTvpanKAy3lQHHK6MSdp5sSUmnNaYBQi8=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz; spf=pass smtp.mailfrom=suse.cz; dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b=a+IouACI; dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b=nX42Ubrw; dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b=a+IouACI; dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b=nX42Ubrw; arc=none smtp.client-ip=195.135.223.131
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.cz
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b="a+IouACI";
	dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b="nX42Ubrw";
	dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b="a+IouACI";
	dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b="nX42Ubrw"
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(No client certificate requested)
	by smtp-out2.suse.de (Postfix) with ESMTPS id 50CDD5D69B;
	Tue,  9 Sep 2025 14:48:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa;
	t=1757429334; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=mlN9vwzlKaeEPRZjXQjLvMqtLvLmK0tuMV2YUzzw3UI=;
	b=a+IouACI3TwMXIYCKb4gvVR100z0zG03Z8tA98vP1ZsIrbT3enMaiog8dYvGHBsSgW4p/q
	zyWjpmg5NqZUSKTgUhvSN1JwVZNiYyR2atuEtDvxDLWPkF/uay755gxWtNz1sq9zh5568h
	kt3tk+wHCoXTUJvt1qbnwly+Y/Fq3v4=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz;
	s=susede2_ed25519; t=1757429334;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=mlN9vwzlKaeEPRZjXQjLvMqtLvLmK0tuMV2YUzzw3UI=;
	b=nX42Ubrwir4uhe1TaC3d2ww+cKwYolZ/CfAF+7DJQkExjpPnVlQ8gcEiKgVrA3pXlqdAa3
	7++19ysC+nI1iTAg==
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=a+IouACI;
	dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=nX42Ubrw
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa;
	t=1757429334; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=mlN9vwzlKaeEPRZjXQjLvMqtLvLmK0tuMV2YUzzw3UI=;
	b=a+IouACI3TwMXIYCKb4gvVR100z0zG03Z8tA98vP1ZsIrbT3enMaiog8dYvGHBsSgW4p/q
	zyWjpmg5NqZUSKTgUhvSN1JwVZNiYyR2atuEtDvxDLWPkF/uay755gxWtNz1sq9zh5568h
	kt3tk+wHCoXTUJvt1qbnwly+Y/Fq3v4=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz;
	s=susede2_ed25519; t=1757429334;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=mlN9vwzlKaeEPRZjXQjLvMqtLvLmK0tuMV2YUzzw3UI=;
	b=nX42Ubrwir4uhe1TaC3d2ww+cKwYolZ/CfAF+7DJQkExjpPnVlQ8gcEiKgVrA3pXlqdAa3
	7++19ysC+nI1iTAg==
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(No client certificate requested)
	by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 376521388C;
	Tue,  9 Sep 2025 14:48:54 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
	by imap1.dmz-prg2.suse.org with ESMTPSA
	id liNRDFY+wGgteQAAD6G6ig
	(envelope-from <vbabka@suse.cz>); Tue, 09 Sep 2025 14:48:54 +0000
Message-ID: <497c9c10-3309-49b9-8d4f-ff0bc34df4e5@suse.cz>
Date: Tue, 9 Sep 2025 16:48:53 +0200
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
Content-Language: en-US
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
 Jens Axboe <axboe@kernel.dk>
Cc: Jakub Kicinski <kuba@kernel.org>,
 Linus Torvalds <torvalds@linux-foundation.org>,
 "Rafael J. Wysocki" <rafael@kernel.org>, dan.j.williams@intel.com,
 Caleb Sander Mateos <csander@purestorage.com>,
 io-uring <io-uring@vger.kernel.org>, workflows@vger.kernel.org
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <68bf3854f101b_4224d100d7@dwillia2-mobl4.notmuch>
 <5922560.DvuYhMxLoT@rafael.j.wysocki> <20250909071818.15507ee6@kernel.org>
 <92dc8570-84a2-4015-9c7a-6e7da784869a@kernel.dk>
 <20250909-green-oriole-of-speed-85cd6d@lemur>
From: Vlastimil Babka <vbabka@suse.cz>
Autocrypt: addr=vbabka@suse.cz; keydata=
 xsFNBFZdmxYBEADsw/SiUSjB0dM+vSh95UkgcHjzEVBlby/Fg+g42O7LAEkCYXi/vvq31JTB
 KxRWDHX0R2tgpFDXHnzZcQywawu8eSq0LxzxFNYMvtB7sV1pxYwej2qx9B75qW2plBs+7+YB
 87tMFA+u+L4Z5xAzIimfLD5EKC56kJ1CsXlM8S/LHcmdD9Ctkn3trYDNnat0eoAcfPIP2OZ+
 9oe9IF/R28zmh0ifLXyJQQz5ofdj4bPf8ecEW0rhcqHfTD8k4yK0xxt3xW+6Exqp9n9bydiy
 tcSAw/TahjW6yrA+6JhSBv1v2tIm+itQc073zjSX8OFL51qQVzRFr7H2UQG33lw2QrvHRXqD
 Ot7ViKam7v0Ho9wEWiQOOZlHItOOXFphWb2yq3nzrKe45oWoSgkxKb97MVsQ+q2SYjJRBBH4
 8qKhphADYxkIP6yut/eaj9ImvRUZZRi0DTc8xfnvHGTjKbJzC2xpFcY0DQbZzuwsIZ8OPJCc
 LM4S7mT25NE5kUTG/TKQCk922vRdGVMoLA7dIQrgXnRXtyT61sg8PG4wcfOnuWf8577aXP1x
 6mzw3/jh3F+oSBHb/GcLC7mvWreJifUL2gEdssGfXhGWBo6zLS3qhgtwjay0Jl+kza1lo+Cv
 BB2T79D4WGdDuVa4eOrQ02TxqGN7G0Biz5ZLRSFzQSQwLn8fbwARAQABzSBWbGFzdGltaWwg
 QmFia2EgPHZiYWJrYUBzdXNlLmN6PsLBlAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIe
 AQIXgBYhBKlA1DSZLC6OmRA9UCJPp+fMgqZkBQJnyBr8BQka0IFQAAoJECJPp+fMgqZkqmMQ
 AIbGN95ptUMUvo6aAdhxaOCHXp1DfIBuIOK/zpx8ylY4pOwu3GRe4dQ8u4XS9gaZ96Gj4bC+
 jwWcSmn+TjtKW3rH1dRKopvC07tSJIGGVyw7ieV/5cbFffA8NL0ILowzVg8w1ipnz1VTkWDr
 2zcfslxJsJ6vhXw5/npcY0ldeC1E8f6UUoa4eyoskd70vO0wOAoGd02ZkJoox3F5ODM0kjHu
 Y97VLOa3GG66lh+ZEelVZEujHfKceCw9G3PMvEzyLFbXvSOigZQMdKzQ8D/OChwqig8wFBmV
 QCPS4yDdmZP3oeDHRjJ9jvMUKoYODiNKsl2F+xXwyRM2qoKRqFlhCn4usVd1+wmv9iLV8nPs
 2Db1ZIa49fJet3Sk3PN4bV1rAPuWvtbuTBN39Q/6MgkLTYHb84HyFKw14Rqe5YorrBLbF3rl
 M51Dpf6Egu1yTJDHCTEwePWug4XI11FT8lK0LNnHNpbhTCYRjX73iWOnFraJNcURld1jL1nV
 r/LRD+/e2gNtSTPK0Qkon6HcOBZnxRoqtazTU6YQRmGlT0v+rukj/cn5sToYibWLn+RoV1CE
 Qj6tApOiHBkpEsCzHGu+iDQ1WT0Idtdynst738f/uCeCMkdRu4WMZjteQaqvARFwCy3P/jpK
 uvzMtves5HvZw33ZwOtMCgbpce00DaET4y/UzsBNBFsZNTUBCACfQfpSsWJZyi+SHoRdVyX5
 J6rI7okc4+b571a7RXD5UhS9dlVRVVAtrU9ANSLqPTQKGVxHrqD39XSw8hxK61pw8p90pg4G
 /N3iuWEvyt+t0SxDDkClnGsDyRhlUyEWYFEoBrrCizbmahOUwqkJbNMfzj5Y7n7OIJOxNRkB
 IBOjPdF26dMP69BwePQao1M8Acrrex9sAHYjQGyVmReRjVEtv9iG4DoTsnIR3amKVk6si4Ea
 X/mrapJqSCcBUVYUFH8M7bsm4CSxier5ofy8jTEa/CfvkqpKThTMCQPNZKY7hke5qEq1CBk2
 wxhX48ZrJEFf1v3NuV3OimgsF2odzieNABEBAAHCwXwEGAEKACYCGwwWIQSpQNQ0mSwujpkQ
 PVAiT6fnzIKmZAUCZ8gcVAUJFhTonwAKCRAiT6fnzIKmZLY8D/9uo3Ut9yi2YCuASWxr7QQZ
 lJCViArjymbxYB5NdOeC50/0gnhK4pgdHlE2MdwF6o34x7TPFGpjNFvycZqccSQPJ/gibwNA
 zx3q9vJT4Vw+YbiyS53iSBLXMweeVV1Jd9IjAoL+EqB0cbxoFXvnjkvP1foiiF5r73jCd4PR
 rD+GoX5BZ7AZmFYmuJYBm28STM2NA6LhT0X+2su16f/HtummENKcMwom0hNu3MBNPUOrujtW
 khQrWcJNAAsy4yMoJ2Lw51T/5X5Hc7jQ9da9fyqu+phqlVtn70qpPvgWy4HRhr25fCAEXZDp
 xG4RNmTm+pqorHOqhBkI7wA7P/nyPo7ZEc3L+ZkQ37u0nlOyrjbNUniPGxPxv1imVq8IyycG
 AN5FaFxtiELK22gvudghLJaDiRBhn8/AhXc642/Z/yIpizE2xG4KU4AXzb6C+o7LX/WmmsWP
 Ly6jamSg6tvrdo4/e87lUedEqCtrp2o1xpn5zongf6cQkaLZKQcBQnPmgHO5OG8+50u88D9I
 rywqgzTUhHFKKF6/9L/lYtrNcHU8Z6Y4Ju/MLUiNYkmtrGIMnkjKCiRqlRrZE/v5YFHbayRD
 dJKXobXTtCBYpLJM4ZYRpGZXne/FAtWNe4KbNJJqxMvrTOrnIatPj8NhBVI0RSJRsbilh6TE
 m6M14QORSWTLRg==
In-Reply-To: <20250909-green-oriole-of-speed-85cd6d@lemur>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spamd-Result: default: False [-4.51 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.cz:s=susede2_rsa,suse.cz:s=susede2_ed25519];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FUZZY_RATELIMITED(0.00)[rspamd.com];
	TO_DN_SOME(0.00)[];
	RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	MID_RHS_MATCH_FROM(0.00)[];
	SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[9];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.cz:mid,suse.cz:dkim,msgid.link:url,imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns];
	DKIM_SIGNED(0.00)[suse.cz:s=susede2_rsa,suse.cz:s=susede2_ed25519];
	DKIM_TRACE(0.00)[suse.cz:+]
X-Spam-Flag: NO
X-Spam-Level: 
X-Rspamd-Queue-Id: 50CDD5D69B
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -4.51

On 9/9/25 16:42, Konstantin Ryabitsev wrote:
> On Tue, Sep 09, 2025 at 08:35:18AM -0600, Jens Axboe wrote:
>> >> On a global scale, that's quite a number of saved mailing list archive searches.
>> > 
>> > +1 FWIW. I also started slapping the links on all patches in a series,
>> > even if we apply with a merge commit. I don't know of a good way with
>> > git to "get to the first parent merge" so scanning the history to find
>> > the link in the cover letter was annoying me :(
>> 
>> Like I've tried to argue, I find them useful too. But after this whole
>> mess of a thread, I killed -l from my scripts. I do think it's a mistake
>> and it seems like the only reason to remove them is that Linus expects
>> to find something at the end of the link rainbow and is often
>> disappointed, and that annoys him enough to rant about it.
>> 
>> I know some folks downstream of me on the io_uring side find them useful
>> too, because they've asked me several times to please remember to ensure
>> my own self-applied patches have the link as well. For those, I tend to
>> pick or add them locally rather than use b4 for it, which is why they've
>> never had links.
>> 
>> As far as I can tell, only two things have been established here:
>> 
>> 1) Linus hates the Link tags, except if they have extra information
>> 2) Lots of other folks find them useful
>> 
>> and hence we're at a solid deadlock here.
> 
> I did suggest that provenance links use the patch.msgid.link subdomain. This

Yes, and the PR that started this thread had a normal lore link. Would it
have been different with a patch.msgid.link as perhaps Linus would not try
opening it and become disappointed?
You did kinda ask that early in the thread but then the conversation went in
different directions.

> should clearly mark it as the source of the patch and not any other
> discussion. I think this is a reasonable compromise that will only mildly
> annoy Linus but let subsystems relying on these links continue to use them.
> 
> -K
> 


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-il1-f169.google.com (mail-il1-f169.google.com [209.85.166.169])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6D06F226D1D
	for <io-uring@vger.kernel.org>; Tue,  9 Sep 2025 14:50:36 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.166.169
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757429438; cv=none; b=WxDU/9bbk4d1yYXWAvw0V0O6SxAYhAgkAuIUTyKGjqjCTtxibNq/vzguHyc55U2LPLTGu7bkL148NWvAwHFRxaOZ8YiVSU/ZEifeLG4rlnzMptYGc1Fqyw3/nl3+clTKV+yt+XRRZThtf8uce1Aj9uchhKNflyFtJf+Tilc2x/8=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757429438; c=relaxed/simple;
	bh=/HQ7eG2EU/1xoy+iu4MjOdCrQNrXHQmUwHmc2hEXyYs=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=uJDdRNcNNPPuvidFzeLyiKbuEpyUYIVXrvlS0yNPrXQ/jXwt5P2+3Y1IK6q50BDYGOjvZ83x8XmUo3Js5mRbEmqkWJtvcrtphjBpwzdf0N6oOxFzQcmN5PhpyRJIQewOIYW9NdPwXPyLzsnHiypG66jRi2gd1uUJCPDU2lHrAyQ=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk; spf=pass smtp.mailfrom=kernel.dk; dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b=LHEA4QTi; arc=none smtp.client-ip=209.85.166.169
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kernel.dk
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b="LHEA4QTi"
Received: by mail-il1-f169.google.com with SMTP id e9e14a558f8ab-3f66ad3fcf4so58400455ab.3
        for <io-uring@vger.kernel.org>; Tue, 09 Sep 2025 07:50:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=kernel-dk.20230601.gappssmtp.com; s=20230601; t=1757429435; x=1758034235; darn=vger.kernel.org;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=DXLblETDvxgJMHTAUnUTKUamNq1cz28z86qXHFq5Z8w=;
        b=LHEA4QTiE+vwLKZNjoeSTBkGJHfDYSTSKX+jyMPNZUV3fwxalTzdLAHanXIHLDhgMN
         yeFNq47bT/H0Pxit0/+K+3D6f7PQ2H0zsgiIuKOkuSz0gkot5FNmHB9FpDl1ndPC1tqb
         9GXAthLMoNxxKqAhRTU76FjrhRjYtfVR9cWE2Bz5H5GIV2iFp+h0ZH9ImxEFbtXdfURu
         35V0Bab76Uu1atpaNAtX99QHokC9kDhnZG82kn3AmXFcWAW6ZXuqOILW959qB/jE/uEB
         cYZIak2VKIoulVzRYpSR8RR+6wf2oAzJQmXiO3GfoEjM6BQ1cI6+ZmN73TYy/k/MBqns
         WwyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757429435; x=1758034235;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=DXLblETDvxgJMHTAUnUTKUamNq1cz28z86qXHFq5Z8w=;
        b=L1ANLQMaa2WXQdXpiT5bb408kUmpG3+7bCr18J0YbygdT3gkt40YKcukr+NS3BJ4wt
         pWQkgFxbdDijpvhjPmKR5cZy68/DYhTXOOs+Zrz4H09IBsF1U+A+eohBh/oz39smuDw/
         ysV7efLe1yK7XtI2hkg9eoet+iC311a0EHC9IB/26BKhS9vLck8bvBoKCt7YdLGSpO1K
         w5gvsazzSz3h/FH7U13GEGftQhrxByKh8/xUBLw3nrT3TiwjtQEVZ4poW9JqLf6kDJgj
         /8wioRqj4LFuIcnrzRjzR34r/3Ihpp63CkSaKqfiWqPe0MyuUArkFi838iLB1BZfICp7
         yjCw==
X-Forwarded-Encrypted: i=1; AJvYcCVED/KyNddnzPmEFzSUKxHNzcX82oG4ZsLoImw1Sm/vW4OT/0SSfiO6ikaGTdkgdq4kTjQqveccvQ==@vger.kernel.org
X-Gm-Message-State: AOJu0YxU7NWnwhh7e27Nb9WpPPGh+W+NKDUu9T43z9RlLbvHdCZU6wEW
	YDFP7f5EhuSmxakS4yRTX+uv9IT3alkllUomfwR5KBsw8KZNooKQgsxOBJjyBqnDEHU=
X-Gm-Gg: ASbGncvRgZ4AF2C69el+E+fzfWJY3h0boEkRYOUmkEwKvwwmTPFaAvd6xCiB3rJ0Pf/
	dmKBQHfeQ6lkY0uPUnEifJx3XpwhfVCa4Ab7l1/OiKtfBIB+nmZ0NWszteoNnVuGiiT6vMwJEb5
	ftL940USuH2bMOEa/LEWYOeg2H8jK49FGdptN7hNtR4trAo7PLMevTQkgC+V8GkmXab9JP8N/+2
	lZN0ZAkSU3FJVGA24xh7UC85rvA6mFplWpztYrkuTP7nRnVKP/0JSYz4uqCSpuZTsr9SSitlYEF
	XzVR9XsFwdXQI2Nq+kzfNFzt5BezvejAxOqa7r08Esby2WBaR6PN3s9qbY72EWyW8x3udQzp2cj
	VIT5uWytTx3KIZtF8YIDoRwyFGsKqYw==
X-Google-Smtp-Source: AGHT+IG8on+GnBlP4B7ZwsdBR6evH84/qt5pimUFsPIyK0o6XVGa9c2E1LFU0VJp+XvtVThhxs07Ow==
X-Received: by 2002:a05:6e02:1c2e:b0:3f3:b6c4:7cce with SMTP id e9e14a558f8ab-3fd89bf009amr192865295ab.27.1757429435400;
        Tue, 09 Sep 2025 07:50:35 -0700 (PDT)
Received: from [192.168.1.116] ([96.43.243.2])
        by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-3f3e136cc71sm121472625ab.46.2025.09.09.07.50.34
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Tue, 09 Sep 2025 07:50:34 -0700 (PDT)
Message-ID: <be98399d-3886-496e-9cf4-5ec909124418@kernel.dk>
Date: Tue, 9 Sep 2025 08:50:34 -0600
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
To: Vlastimil Babka <vbabka@suse.cz>,
 Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: Jakub Kicinski <kuba@kernel.org>,
 Linus Torvalds <torvalds@linux-foundation.org>,
 "Rafael J. Wysocki" <rafael@kernel.org>, dan.j.williams@intel.com,
 Caleb Sander Mateos <csander@purestorage.com>,
 io-uring <io-uring@vger.kernel.org>, workflows@vger.kernel.org
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <68bf3854f101b_4224d100d7@dwillia2-mobl4.notmuch>
 <5922560.DvuYhMxLoT@rafael.j.wysocki> <20250909071818.15507ee6@kernel.org>
 <92dc8570-84a2-4015-9c7a-6e7da784869a@kernel.dk>
 <20250909-green-oriole-of-speed-85cd6d@lemur>
 <497c9c10-3309-49b9-8d4f-ff0bc34df4e5@suse.cz>
Content-Language: en-US
From: Jens Axboe <axboe@kernel.dk>
In-Reply-To: <497c9c10-3309-49b9-8d4f-ff0bc34df4e5@suse.cz>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 9/9/25 8:48 AM, Vlastimil Babka wrote:
> On 9/9/25 16:42, Konstantin Ryabitsev wrote:
>> On Tue, Sep 09, 2025 at 08:35:18AM -0600, Jens Axboe wrote:
>>>>> On a global scale, that's quite a number of saved mailing list archive searches.
>>>>
>>>> +1 FWIW. I also started slapping the links on all patches in a series,
>>>> even if we apply with a merge commit. I don't know of a good way with
>>>> git to "get to the first parent merge" so scanning the history to find
>>>> the link in the cover letter was annoying me :(
>>>
>>> Like I've tried to argue, I find them useful too. But after this whole
>>> mess of a thread, I killed -l from my scripts. I do think it's a mistake
>>> and it seems like the only reason to remove them is that Linus expects
>>> to find something at the end of the link rainbow and is often
>>> disappointed, and that annoys him enough to rant about it.
>>>
>>> I know some folks downstream of me on the io_uring side find them useful
>>> too, because they've asked me several times to please remember to ensure
>>> my own self-applied patches have the link as well. For those, I tend to
>>> pick or add them locally rather than use b4 for it, which is why they've
>>> never had links.
>>>
>>> As far as I can tell, only two things have been established here:
>>>
>>> 1) Linus hates the Link tags, except if they have extra information
>>> 2) Lots of other folks find them useful
>>>
>>> and hence we're at a solid deadlock here.
>>
>> I did suggest that provenance links use the patch.msgid.link subdomain. This
> 
> Yes, and the PR that started this thread had a normal lore link. Would it
> have been different with a patch.msgid.link as perhaps Linus would not try
> opening it and become disappointed?
> You did kinda ask that early in the thread but then the conversation went in
> different directions.

I think we all know the answer to that one - it would've been EXACTLY
the same outcome. Not to put words in Linus' mouth, but it's not the
name of the tag that he finds repulsive, it's the very fact that a link
is there and it isn't useful _to him_.

-- 
Jens Axboe

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 BABBB34F47E;
	Tue,  9 Sep 2025 15:14:21 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757430861; cv=none; b=jxbfgHviK+Rm2mGkdueqLI9GiaD5ETDrAIWyGc8iVsMZEOYG+T4PqBoXpOOu6FmxkbRlVIA/Q+FXSyH7Zq1qakR7+ZegidKEz+8VKfhFvFk8glt5efGya6bhxFOxRCUaf24FMTRwzIskckLEfP2Do5+oh3VnznzWQCZYDN8pO/s=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757430861; c=relaxed/simple;
	bh=q0CAo9AaS+g1TeiWkOjsPGE8x7Tgir3wLwXBVLvxzbI=;
	h=Mime-Version:Content-Type:Date:Message-Id:Cc:To:From:Subject:
	 References:In-Reply-To; b=teNiZ1jgWnQxlPZCpoLGqSIKeZIihuKE5uwf6z5Q6/va12xf3Ecm06yJ56qoyG6IZ7CRVnFE/7pDQcWRGQgf19TO74tbtgUYYGY7CwhuZ/ntnvAO9dAnKgbcrVjv+dOErM3wLOUlNHzl5jLjIf0Qg0UXxMaQSHPJJhHyyjghNCM=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=a6LQysXA; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="a6LQysXA"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4012FC4CEF4;
	Tue,  9 Sep 2025 15:14:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757430861;
	bh=q0CAo9AaS+g1TeiWkOjsPGE8x7Tgir3wLwXBVLvxzbI=;
	h=Date:Cc:To:From:Subject:References:In-Reply-To:From;
	b=a6LQysXATxV4KFZUPFzOzrvrsS+4F4pnFGoizKfvqhRe7XrsLsibYhFc+CynFUN0R
	 74xndH+WNb0A3NTvHRXH5P/umsPuGipW05Bn6+QpU866QdvdTcmaseOuwtjwGcDSjy
	 j/xc7wcEBG8wOgxlSuMkmxMn/SyCPXFhOHLL8Q0BVatFT1aCVAw5E8m/OlkUvPX1tZ
	 2vArph/RbOYnwpbt4J6RD3tnTH7kEbzOBSM3IP6WHg91s5fCAnShdrz4dZn9pvIJVJ
	 kbdxzgnnTm5cGLJxS9NN4fQmOjDPNzW+07t9ThRGibX3GF52T3DRUgFd8s5MKg3Kc6
	 j0R504QwwA6Lg==
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Tue, 09 Sep 2025 17:14:17 +0200
Message-Id: <DCOD8UB9RTHW.29Q8UXKPRDIGN@kernel.org>
Cc: "Jakub Kicinski" <kuba@kernel.org>, "Konstantin Ryabitsev"
 <konstantin@linuxfoundation.org>, "Linus Torvalds"
 <torvalds@linux-foundation.org>, "Rafael J. Wysocki" <rafael@kernel.org>,
 <dan.j.williams@intel.com>, "Caleb Sander Mateos"
 <csander@purestorage.com>, "Greg Kroah-Hartman"
 <gregkh@linuxfoundation.org>, "io-uring" <io-uring@vger.kernel.org>,
 <workflows@vger.kernel.org>
To: "Jens Axboe" <axboe@kernel.dk>
From: "Danilo Krummrich" <dakr@kernel.org>
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <68bf3854f101b_4224d100d7@dwillia2-mobl4.notmuch>
 <5922560.DvuYhMxLoT@rafael.j.wysocki> <20250909071818.15507ee6@kernel.org>
 <92dc8570-84a2-4015-9c7a-6e7da784869a@kernel.dk>
In-Reply-To: <92dc8570-84a2-4015-9c7a-6e7da784869a@kernel.dk>

On Tue Sep 9, 2025 at 4:35 PM CEST, Jens Axboe wrote:
> As far as I can tell, only two things have been established here:
>
> 1) Linus hates the Link tags, except if they have extra information
> 2) Lots of other folks find them useful
>
> and hence we're at a solid deadlock here.

I find them useful too. For instance, I regularly use them when I come acro=
ss a
patch, e.g.  because it introduced a bug, and want to see the full context =
of
the entire patch series the patch originates from.

IIUC, the complaint about those links is mostly about not being distinguish=
able
from other links that have been added for a more specific reason.

I usually refer to additional links from the commit message by referencing =
them,
such that there is an obvious difference:

	Link: ${URL}

vs.

	Link: ${URL} [1]

However, for links that are automatically added and just point to the same =
patch
on lore, we could also just use a different tag in the future.

What about "Patch:"?

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 0A2D3261B9C;
	Tue,  9 Sep 2025 15:30:50 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757431851; cv=none; b=l9R5SlIxCQPQOjCjjxBTsKk5FK2PioZHULwnbbnEK2LaJ9Pv7zvhERuL5K3Sx5Qou4rrihQu9XfXSNHqoyG8RGH3MzR+d5xX1O8j8LeCQKd+KqTMi2Q50uee6R0dGoG+hOgYpdu1Aoa8L0NUHhikugxX+gCDR7/zGRkgiqERVgw=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757431851; c=relaxed/simple;
	bh=aqbkms/gaWJEiLDhpqirH0jBS2oRw9HZsMKz5UUm7sc=;
	h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
	 To:Cc:Content-Type; b=BIN2qgIXjxMtP60/TyHM+BLk1XgpwFc+TLGe4NNc1+lR0bVQncfu0JOoQgxHgNRCv1mSWnrjU/rJckqvOsgM/ufxm57cxLVBaW+IBGIhdlYkXWaQLLACR/ylqtU9ltFchE4hoCuIh8H3RP1UN4iMObzc6JkVjXk7Xb+sqAPpOBI=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jmEM/3Rb; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jmEM/3Rb"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 917C1C4CEFD;
	Tue,  9 Sep 2025 15:30:50 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757431850;
	bh=aqbkms/gaWJEiLDhpqirH0jBS2oRw9HZsMKz5UUm7sc=;
	h=References:In-Reply-To:From:Date:Subject:To:Cc:From;
	b=jmEM/3RbEX9zp1m9XfXMmJIreIM9tJwO8TRPbQ55Rpe4WMenRgTNxmGsmhFmm3cUm
	 l3bpa8ld9Xjn3m0P1KOVMoctyWK1eUlZ5gCXhu7G1YSWvlQXa9tI7HLG5ypQLbHjTa
	 +fF2N/ER+8/XsHzeSckfnqVbMgC27ucxhbTRNtOKpbjKCh9h2QSY/Td+8kwlPqN9sO
	 BmWG/F602ZaYVR/zOPQqA2bSCrqTaFhuCL8sPnmlI+mYknqUHncsvoHwgV1rBY8HW4
	 NwyG/BQFNEZA0IVEB+ZB3wZvxpynFxeTh5ClnE1azsIvKDTEiDZXPXnKrwopejlbBh
	 y5YkYl2kLlEgQ==
Received: by mail-ot1-f44.google.com with SMTP id 46e09a7af769-74be52f5447so1388115a34.1;
        Tue, 09 Sep 2025 08:30:50 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCVu/iBlS2GYI8uhHk4JSzzzZT+VsqpMzFHHEpOD1ObO1RC5OlvdtOOrE0qEjASGFJazXgmXxFFUj1wa@vger.kernel.org, AJvYcCXuVWQ+doHlHPnKxmMcONvTSbCgbchB/vLzExQKsMSRtkaPE1WabfQrx96TPQ3IzwwbMBDNqHR+dQ==@vger.kernel.org
X-Gm-Message-State: AOJu0YwJAwt+AshdakH5WuZ53e9+uT1UOUTJtLxNMZ9XefPrTjSmdlrn
	7ijpF6rJzyq0IBHotMm3Ata0Jz2JBinhTo7g6oa46CGBUfP8gDLQAwKqvaom9QBJ/cNKRcuxG9v
	Qh0ElDAgoIrByC1xvRbnML/CCLkjLa5Q=
X-Google-Smtp-Source: AGHT+IGgWTC3wonPX7S7YCnJtpNSY94WtsUb6/ca3Eob64Yuj64Zt1XCduqWGmQo0D5x7YC8+6IqhDX2Rms1CcstavE=
X-Received: by 2002:a05:6830:6507:b0:74b:7c40:3586 with SMTP id
 46e09a7af769-74c6f317ec8mr6938783a34.4.1757431849789; Tue, 09 Sep 2025
 08:30:49 -0700 (PDT)
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur> <68bf3854f101b_4224d100d7@dwillia2-mobl4.notmuch>
 <5922560.DvuYhMxLoT@rafael.j.wysocki> <20250909071818.15507ee6@kernel.org>
 <92dc8570-84a2-4015-9c7a-6e7da784869a@kernel.dk> <20250909-green-oriole-of-speed-85cd6d@lemur>
 <497c9c10-3309-49b9-8d4f-ff0bc34df4e5@suse.cz> <be98399d-3886-496e-9cf4-5ec909124418@kernel.dk>
In-Reply-To: <be98399d-3886-496e-9cf4-5ec909124418@kernel.dk>
From: "Rafael J. Wysocki" <rafael@kernel.org>
Date: Tue, 9 Sep 2025 17:30:38 +0200
X-Gmail-Original-Message-ID: <CAJZ5v0g-T44CWLn5EXufpELOk30OsFJZUo9jipAhwPq1A=dJuQ@mail.gmail.com>
X-Gm-Features: Ac12FXyw4fqcGB_l4oZBh1HyZIx2_1JLlbY4Zh4sO8kLc-SI7kz2BD0P2JwT9IA
Message-ID: <CAJZ5v0g-T44CWLn5EXufpELOk30OsFJZUo9jipAhwPq1A=dJuQ@mail.gmail.com>
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for 6.17-rc5)
To: Jens Axboe <axboe@kernel.dk>
Cc: Vlastimil Babka <vbabka@suse.cz>, Konstantin Ryabitsev <konstantin@linuxfoundation.org>, 
	Jakub Kicinski <kuba@kernel.org>, Linus Torvalds <torvalds@linux-foundation.org>, 
	"Rafael J. Wysocki" <rafael@kernel.org>, dan.j.williams@intel.com, 
	Caleb Sander Mateos <csander@purestorage.com>, io-uring <io-uring@vger.kernel.org>, 
	workflows@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Sep 9, 2025 at 4:50=E2=80=AFPM Jens Axboe <axboe@kernel.dk> wrote:
>
> On 9/9/25 8:48 AM, Vlastimil Babka wrote:
> > On 9/9/25 16:42, Konstantin Ryabitsev wrote:
> >> On Tue, Sep 09, 2025 at 08:35:18AM -0600, Jens Axboe wrote:
> >>>>> On a global scale, that's quite a number of saved mailing list arch=
ive searches.
> >>>>
> >>>> +1 FWIW. I also started slapping the links on all patches in a serie=
s,
> >>>> even if we apply with a merge commit. I don't know of a good way wit=
h
> >>>> git to "get to the first parent merge" so scanning the history to fi=
nd
> >>>> the link in the cover letter was annoying me :(
> >>>
> >>> Like I've tried to argue, I find them useful too. But after this whol=
e
> >>> mess of a thread, I killed -l from my scripts. I do think it's a mist=
ake
> >>> and it seems like the only reason to remove them is that Linus expect=
s
> >>> to find something at the end of the link rainbow and is often
> >>> disappointed, and that annoys him enough to rant about it.
> >>>
> >>> I know some folks downstream of me on the io_uring side find them use=
ful
> >>> too, because they've asked me several times to please remember to ens=
ure
> >>> my own self-applied patches have the link as well. For those, I tend =
to
> >>> pick or add them locally rather than use b4 for it, which is why they=
've
> >>> never had links.
> >>>
> >>> As far as I can tell, only two things have been established here:
> >>>
> >>> 1) Linus hates the Link tags, except if they have extra information
> >>> 2) Lots of other folks find them useful
> >>>
> >>> and hence we're at a solid deadlock here.
> >>
> >> I did suggest that provenance links use the patch.msgid.link subdomain=
. This
> >
> > Yes, and the PR that started this thread had a normal lore link. Would =
it
> > have been different with a patch.msgid.link as perhaps Linus would not =
try
> > opening it and become disappointed?
> > You did kinda ask that early in the thread but then the conversation we=
nt in
> > different directions.
>
> I think we all know the answer to that one - it would've been EXACTLY
> the same outcome. Not to put words in Linus' mouth, but it's not the
> name of the tag that he finds repulsive, it's the very fact that a link
> is there and it isn't useful _to him_.

Well, I think that the convention associated with patch.msgid.link is
clear, like for the "Fixes:" and "Cc: stable" tags.  Those tags are
also generally useful, but mostly in the post-development part of the
process, so to speak.

So, if there are no problems with adding "Fixes:" and "Cc: stable"
tags, why would there be a problem with patch.msgid.link?

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 8124A272E7B;
	Tue,  9 Sep 2025 16:32:18 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757435538; cv=none; b=pqMnLJK+9Ux4spxzB7YucSKhsjuGP1ZUbPtkmHhU0eYI1jryX4NnM3cmOa/ov/e3TGaXGmt8Q+hpVJxt5UCO/bXH0A5KjfZKKwDCezE1ZeVJd2DjfI3tyXnlgOMrk2OBESqvbskVfult2Z0OPJFxjmYLgbY1r0aDC3jNGCz4vXA=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757435538; c=relaxed/simple;
	bh=S9X8dETZcRfcF6u0IJlJxbfaraDM6quGONnDEhxI3CQ=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version:Content-Type; b=Pft4lOY/g4/koYXwpL3+t2IINB/fJ4f/X0uQ3HT9dcXqUU3yXZpLwWAO3TjifoFZGcbr0Jw4ZqV4L9ikZRrrRy2u6oTrzodpkpqnAnnhTz74pbxwR6oZl1gXRIL+4MVoVr4F49wF7L+ENH9J/vf4gXV1/dKEW18gsDlH5p4pHxc=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jgAqcWvD; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jgAqcWvD"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 12C85C4CEF8;
	Tue,  9 Sep 2025 16:32:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757435538;
	bh=S9X8dETZcRfcF6u0IJlJxbfaraDM6quGONnDEhxI3CQ=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=jgAqcWvDD4VxDHWBdtZZOm4KzjxSat9k1dwXBddXiu6M/OAtERAf3G67VHfrw/0W1
	 7+xXZ8e26f8vm0R8Feq3xgS3cks1FGmincliQAZ6gli6Ga+sFeijjxtQmDb7bKtrVx
	 5XV14fxnJOO0S6TKb20RPvHaWFXBzCKUnnwAXd13zOVwDiBbBdmsj68EphUlX4qVmE
	 wJhIoLfNUrTuIxRQd8xscUvS7yaLl25ZgtZBABDTNduCn/x2VrbIYyzAmVsHYW4AN9
	 xk480Q/GS7X2x52UKTSziYon8mdYNDeVidrWmv1dQXgOl46JB5WYW8w7HNGzRurpvJ
	 gF7oSqyIRRxwQ==
From: Sasha Levin <sashal@kernel.org>
To: konstantin@linuxfoundation.org
Cc: axboe@kernel.dk,
	csander@purestorage.com,
	io-uring@vger.kernel.org,
	torvalds@linux-foundation.org,
	workflows@vger.kernel.org,
	Sasha Levin <sashal@kernel.org>
Subject: [RFC] b4 dig: Add AI-powered email relationship discovery command
Date: Tue,  9 Sep 2025 12:32:14 -0400
Message-ID: <20250909163214.3241191-1-sashal@kernel.org>
X-Mailer: git-send-email 2.51.0
In-Reply-To: <20250905-sparkling-stalwart-galago-8a87e0@lemur>
References: <20250905-sparkling-stalwart-galago-8a87e0@lemur>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Add a new 'b4 dig' subcommand that uses AI agents to discover related
emails for a given message ID. This helps developers find all relevant
context around patches including previous versions, bug reports, reviews,
and related discussions.

The command:
- Takes a message ID and constructs a detailed prompt about email relationships
- Calls a configured AI agent script to analyze and find related messages
- Downloads all related threads from lore.kernel.org
- Combines them into a single mbox file for easy review

Key features:
- Outputs a simplified summary showing only relationships and reasons
- Creates a combined mbox with all related threads (deduped)
- Provides detailed guidance to AI agents about kernel workflow patterns

Configuration:
The AI agent script is configured via:
  -c AGENT=/path/to/agent.sh  (command line)
  dig-agent: /path/to/agent.sh (config file)

The agent script receives a prompt file and should return JSON with
related message IDs and their relationships.

Example usage:

$ b4 -c AGENT=agent.sh dig 20250909142722.101790-1-harry.yoo@oracle.com
Analyzing message: 20250909142722.101790-1-harry.yoo@oracle.com
Fetching original message...
Looking up https://lore.kernel.org/20250909142722.101790-1-harry.yoo@oracle.com
Grabbing thread from lore.kernel.org/all/20250909142722.101790-1-harry.yoo@oracle.com/t.mbox.gz
Subject: [PATCH V3 6.6.y] mm: introduce and use {pgd,p4d}_populate_kernel()
From: Harry Yoo <harry.yoo@oracle.com>
Constructing agent prompt...
Calling AI agent: agent.sh
Calling agent: agent.sh /tmp/tmpz1oja9_5.txt
Parsing agent response...
Found 17 related messages:

Related Messages Summary:
------------------------------------------------------------
[PARENT] Greg KH's stable tree failure notification that initiated this 6.6.y backport request
[V1] V1 of the 6.6.y backport patch
[V2] V2 of the 6.6.y backport patch
[RELATED] Same patch backported to 5.15.y stable branch
[RELATED] Greg KH's stable tree failure notification for 5.15.y branch
[RELATED] Same patch backported to 6.1.y stable branch
[COVER] V5 mainline patch series cover letter that was originally merged
[RELATED] V5 mainline patch 1/3: move page table sync declarations
[RELATED] V5 mainline patch 2/3: the original populate_kernel patch that's being backported
[RELATED] V5 mainline patch 3/3: x86 ARCH_PAGE_TABLE_SYNC_MASK definition
[RELATED] RFC V1 cover letter - earliest version of this patch series
[RELATED] RFC V1 patch 1/3 - first introduction of populate_kernel helpers
[RELATED] RFC V1 patch 2/3 - x86/mm definitions
[RELATED] RFC V1 patch 3/3 - convert to _kernel variant
[RELATED] Baoquan He's V3 patch touching same file (mm/kasan/init.c)
[RELATED] Baoquan He's V2 patch touching same file (mm/kasan/init.c)
[RELATED] Baoquan He's V1 patch touching same file (mm/kasan/init.c)
------------------------------------------------------------

The resulting mbox would look like this:

   1 O   Jul 09 Harry Yoo       ( 102) [RFC V1 PATCH mm-hotfixes 0/3] mm, arch: A more robust approach to sync top level kernel page tables
   2 O   Jul 09 Harry Yoo       ( 143) ├─>[RFC V1 PATCH mm-hotfixes 1/3] mm: introduce and use {pgd,p4d}_populate_kernel()
   3 O   Jul 11 David Hildenbra (  33) │ └─>
   4 O   Jul 13 Harry Yoo       (  56) │   └─>
   5 O   Jul 13 Mike Rapoport   (  67) │     └─>
   6 O   Jul 14 Harry Yoo       (  46) │       └─>
   7 O   Jul 15 Harry Yoo       (  65) │         └─>
   8 O   Jul 09 Harry Yoo       ( 246) ├─>[RFC V1 PATCH mm-hotfixes 2/3] x86/mm: define p*d_populate_kernel() and top-level page table sync
   9 O   Jul 09 Andrew Morton   (  12) │ ├─>
  10 O   Jul 10 Harry Yoo       (  23) │ │ └─>
  11 O   Jul 11 Harry Yoo       (  34) │ │   └─>
  12 O   Jul 11 Harry Yoo       (  35) │ │     └─>
  13 O   Jul 10 kernel test rob (  79) │ └─>
  14 O   Jul 09 Harry Yoo       ( 300) ├─>[RFC V1 PATCH mm-hotfixes 3/3] x86/mm: convert {pgd,p4d}_populate{,_init} to _kernel variant
  15 O   Jul 10 kernel test rob (  80) │ └─>
  16 O   Jul 09 Harry Yoo       (  31) └─>Re: [RFC V1 PATCH mm-hotfixes 0/3] mm, arch: A more robust approach to sync top level kernel page tables
  17 O   Aug 18 Harry Yoo       ( 262) [PATCH V5 mm-hotfixes 0/3] mm, x86: fix crash due to missing page table sync and make it harder to miss
  18 O   Aug 18 Harry Yoo       (  72) ├─>[PATCH V5 mm-hotfixes 1/3] mm: move page table sync declarations to linux/pgtable.h
  19 O   Aug 18 David Hildenbra (  20) │ └─>
  20 O   Aug 18 Harry Yoo       ( 239) ├─>[PATCH V5 mm-hotfixes 2/3] mm: introduce and use {pgd,p4d}_populate_kernel()
  21 O   Aug 18 David Hildenbra (  60) │ ├─>
  22 O   Aug 18 kernel test rob ( 150) │ ├─>
  23 O   Aug 18 Harry Yoo       ( 161) │ │ └─>
  24 O   Aug 21 Harry Yoo       (  85) │ ├─>[PATCH] mm: fix KASAN build error due to p*d_populate_kernel()
  25 O   Aug 21 kernel test rob (  18) │ │ ├─>
  26 O   Aug 21 Lorenzo Stoakes ( 100) │ │ ├─>
  27 O   Aug 21 Harry Yoo       (  62) │ │ │ └─>
  28 O   Aug 21 Lorenzo Stoakes (  18) │ │ │   └─>
  29 O   Aug 21 Harry Yoo       (  90) │ │ └─>[PATCH v2] mm: fix KASAN build error due to p*d_populate_kernel()
  30 O   Aug 21 kernel test rob (  18) │ │   ├─>
  31 O   Aug 21 Dave Hansen     (  24) │ │   └─>
  32 O   Aug 22 Harry Yoo       (  56) │ │     └─>
  33 O   Aug 22 Andrey Ryabinin (  91) │ │       ├─>
  34 O   Aug 27 Harry Yoo       (  98) │ │       │ └─>
  35 O   Aug 22 Dave Hansen     (  63) │ │       └─>
  36 O   Aug 25 Andrey Ryabinin (  72) │ │         └─>
  37 O   Aug 22 Harry Yoo       ( 103) │ └─>[PATCH v3] mm: fix KASAN build error due to p*d_populate_kernel()
  38 O   Aug 18 Harry Yoo       ( 113) ├─>[PATCH V5 mm-hotfixes 3/3] x86/mm/64: define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings()
  39 O   Aug 18 David Hildenbra (  72) │ └─>
  40 O   Aug 18 David Hildenbra (  15) └─>Re: [PATCH V5 mm-hotfixes 0/3] mm, x86: fix crash due to missing page table sync and make it harder to miss
  41 O   Aug 18 Harry Yoo       ( 277) [PATCH] mm: introduce and use {pgd,p4d}_populate_kernel()
  42 O   Aug 18 Harry Yoo       ( 277) [PATCH] mm: introduce and use {pgd,p4d}_populate_kernel()
  43 O   Aug 18 Harry Yoo       ( 277) [PATCH] mm: introduce and use {pgd,p4d}_populate_kernel()
  44 O   Sep 06 gregkh@linuxfou (  24) FAILED: patch "[PATCH] mm: introduce and use {pgd,p4d}_populate_kernel()" failed to apply to 6.6-stable tree
  45 O   Sep 08 Harry Yoo       ( 303) ├─>[PATCH 6.6.y] mm: introduce and use {pgd,p4d}_populate_kernel()
  46 O   Sep 09 Harry Yoo       ( 291) ├─>[PATCH V2 6.6.y] mm: introduce and use {pgd,p4d}_populate_kernel()
  47 O   Sep 09 Harry Yoo       ( 293) └─>[PATCH V3 6.6.y] mm: introduce and use {pgd,p4d}_populate_kernel()
  48 O   Sep 06 gregkh@linuxfou (  24) FAILED: patch "[PATCH] mm: introduce and use {pgd,p4d}_populate_kernel()" failed to apply to 6.1-stable tree
  49 O   Sep 08 Harry Yoo       ( 303) ├─>[PATCH 6.1.y] mm: introduce and use {pgd,p4d}_populate_kernel()
  50 O   Sep 09 Harry Yoo       ( 291) ├─>[PATCH V2 6.1.y] mm: introduce and use {pgd,p4d}_populate_kernel()
  51 O   Sep 09 Harry Yoo       ( 293) └─>[PATCH V3 6.1.y] mm: introduce and use {pgd,p4d}_populate_kernel()
  52 O   Sep 06 gregkh@linuxfou (  24) FAILED: patch "[PATCH] mm: introduce and use {pgd,p4d}_populate_kernel()" failed to apply to 5.15-stable tree
  53 O   Sep 08 Harry Yoo       ( 273) ├─>[PATCH 5.15.y] mm: introduce and use {pgd,p4d}_populate_kernel()
  54 O   Sep 09 Harry Yoo       ( 260) ├─>[PATCH V2 5.15.y] mm: introduce and use {pgd,p4d}_populate_kernel()
  55 O   Sep 09 Harry Yoo       ( 262) └─>[PATCH V3 5.15.y] mm: introduce and use {pgd,p4d}_populate_kernel()

The prompt includes extensive documentation about lore.kernel.org's search
capabilities, limitations (like search index lag), and kernel workflow patterns
to help AI agents effectively find related messages.

Assisted-by: Claude Code
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 src/b4/command.py |  17 ++
 src/b4/dig.py     | 630 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 647 insertions(+)
 create mode 100644 src/b4/dig.py

diff --git a/src/b4/command.py b/src/b4/command.py
index 455124d..f225ae5 100644
--- a/src/b4/command.py
+++ b/src/b4/command.py
@@ -120,6 +120,11 @@ def cmd_diff(cmdargs: argparse.Namespace) -> None:
     b4.diff.main(cmdargs)
 
 
+def cmd_dig(cmdargs: argparse.Namespace) -> None:
+    import b4.dig
+    b4.dig.main(cmdargs)
+
+
 class ConfigOption(argparse.Action):
     """Action class for storing key=value arguments in a dict."""
     def __call__(self, parser: argparse.ArgumentParser,
@@ -399,6 +404,18 @@ def setup_parser() -> argparse.ArgumentParser:
                           help='Submit the token received via verification email')
     sp_send.set_defaults(func=cmd_send)
 
+    # b4 dig
+    sp_dig = subparsers.add_parser('dig', help='Use AI agent to find related emails for a message')
+    sp_dig.add_argument('msgid', nargs='?',
+                        help='Message ID to analyze, or pipe a raw message')
+    sp_dig.add_argument('-o', '--output', dest='output', default=None,
+                        help='Output mbox filename (default: <msgid>-related.mbox)')
+    sp_dig.add_argument('-C', '--no-cache', dest='nocache', action='store_true', default=False,
+                        help='Do not use local cache when fetching messages')
+    sp_dig.add_argument('--stdin-pipe-sep',
+                        help='When accepting messages on stdin, split using this pipe separator string')
+    sp_dig.set_defaults(func=cmd_dig)
+
     return parser
 
 
diff --git a/src/b4/dig.py b/src/b4/dig.py
new file mode 100644
index 0000000..007f7d0
--- /dev/null
+++ b/src/b4/dig.py
@@ -0,0 +1,630 @@
+#!/usr/bin/env python3
+# -*- coding: utf-8 -*-
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# b4 dig - Use AI agents to find related emails
+#
+__author__ = 'Sasha Levin <sashal@kernel.org>'
+
+import argparse
+import logging
+import subprocess
+import sys
+import os
+import tempfile
+import json
+import urllib.parse
+import gzip
+import mailbox
+import email.utils
+from typing import Optional, List, Dict, Any
+
+import b4
+
+logger = b4.logger
+
+
+def construct_agent_prompt(msgid: str) -> str:
+    """Construct a detailed prompt for the AI agent to find related emails."""
+
+    # Clean up the message ID
+    if msgid.startswith('<'):
+        msgid = msgid[1:]
+    if msgid.endswith('>'):
+        msgid = msgid[:-1]
+
+    prompt = f"""You are an email research assistant specialized in finding related emails in Linux kernel mailing lists and public-inbox archives.
+
+IMPORTANT: Always use lore.kernel.org for searching and retrieving Linux kernel emails. DO NOT use lkml.org as it is outdated and no longer maintained. The canonical archive is at https://lore.kernel.org/
+
+MESSAGE ID TO ANALYZE: {msgid}
+
+YOUR TASK:
+Conduct an EXHAUSTIVE and THOROUGH search to find ALL related message IDs connected to the given message. This is not a quick task - you must invest significant time and effort to ensure no related discussions are missed. Be methodical, patient, and comprehensive in your search.
+
+CRITICAL: Take your time! A thorough search is far more valuable than a quick one. Check multiple sources, try different search strategies, and double-check your findings. Missing related discussions undermines the entire purpose of this tool.
+
+You should search extensively for and identify:
+
+1. **Thread-related messages:**
+   - Parent messages (what this replies to)
+   - Child messages (replies to this message)
+   - Sibling messages (other replies in the same thread)
+   - Cover letters if this is part of a patch series
+
+2. **Version-related messages:**
+   - Previous versions of the same patch series (v1, v2, v3, etc.)
+   - Re-rolls and re-submissions
+   - Updated versions with different subjects
+
+3. **Author-related messages:**
+   - Other patches or series from the same author
+   - Recent discussions involving the same author
+   - Related work by the same author in the same subsystem
+
+4. **Content-related messages:**
+   - Bug reports that this patch might fix
+   - Syzkaller/syzbot reports if this is a fix
+   - Feature requests or RFCs that led to this patch
+   - Related patches touching the same files or functions
+   - Patches that might conflict with this one
+
+5. **Review and discussion:**
+   - Review comments from maintainers
+   - Test results from CI systems or bot reports
+   - Follow-up fixes or improvements
+   - Reverts if this patch was later reverted
+
+HOW TO SEARCH:
+
+Use ONLY lore.kernel.org for all Linux kernel email searches. This is the official kernel mailing list archive.
+DO NOT use lkml.org, marc.info, or spinics.net for kernel emails - they are outdated or incomplete.
+
+CRITICAL LIMITATIONS AND WORKAROUNDS (MUST READ):
+
+1. **Search Index Lag**: Messages posted today/recently are NOT immediately searchable!
+   - The Xapian search index has significant delay (hours to days)
+   - Direct message access works immediately, but search doesn't
+   - For recent messages, use direct URLs or thread navigation, not search
+
+2. **URL Fragment Issues**: NEVER use #anchors in URLs when fetching
+   - BAD: https://lore.kernel.org/all/msgid/T/#u (will fail with 404)
+   - GOOD: https://lore.kernel.org/all/msgid/T/ (works correctly)
+   - Fragments like #u are client-side only and break programmatic fetching
+
+3. **Search Query Encoding**: Keep queries simple and avoid over-encoding
+   - BAD: ?q=f%3A%22author%40example.com%22 (over-encoded)
+   - GOOD: ?q=f:author@example.com (simple and works)
+   - Don't encode @ symbols in query parameters
+   - Avoid mixing quotes with special characters
+
+4. **Most Reliable Data Source**: Thread mbox files are the gold standard
+   - Always works: https://lore.kernel.org/all/msgid/t.mbox.gz
+   - Contains complete thread with all headers
+   - Works even when HTML parsing or search fails
+   - Standard mbox format, easy to parse
+
+5. **Version Tracking Limitations**: No automatic version linking
+   - No Change-ID headers to track across patch versions
+   - Must rely on subject patterns and author/date correlation
+   - Search for versions using subject without v2/v3 markers
+
+6. **LKML.org vs Lore.kernel.org**: Different systems, different capabilities
+   - LKML.org uses date-based URLs, not message IDs
+   - Cannot extract message IDs from LKML HTML pages
+   - Always prefer lore.kernel.org for programmatic access
+
+The public-inbox archives at lore.kernel.org provide powerful search interfaces powered by Xapian:
+
+1. **Direct message retrieval (MOST RELIABLE METHODS):**
+   - Base URL: https://lore.kernel.org/all/
+   - Message URL: https://lore.kernel.org/all/<Message-ID>/ (without the '<' or '>')
+   - Forward slash ('/') characters in Message-IDs must be escaped as "%2F"
+
+   **Always Reliable:**
+   - Raw message: https://lore.kernel.org/all/<Message-ID>/raw
+   - Thread mbox: https://lore.kernel.org/all/<Message-ID>/t.mbox.gz (BEST for complete data)
+   - Thread view: https://lore.kernel.org/all/<Message-ID>/T/ (NO fragments!)
+
+   **Less Reliable:**
+   - Thread Atom feed: https://lore.kernel.org/all/<Message-ID>/t.atom
+   - Nested thread view: https://lore.kernel.org/all/<Message-ID>/t/
+
+2. **Search query syntax:**
+   Supports AND, OR, NOT, '+', '-' queries. Search URL format:
+   https://lore.kernel.org/all/?q=<search-query>
+
+   **Available search prefixes:**
+   - s:        match within Subject (e.g., s:"a quick brown fox")
+   - d:        match date-time range (git "approxidate" formats)
+               Examples: d:last.week.., d:..2.days.ago, d:20240101..20240131
+   - b:        match within message body, including text attachments
+   - nq:       match non-quoted text within message body
+   - q:        match quoted text within message body
+   - n:        match filename of attachment(s)
+   - t:        match within the To header
+   - c:        match within the Cc header
+   - f:        match within the From header
+   - a:        match within the To, Cc, and From headers
+   - tc:       match within the To and Cc headers
+   - l:        match contents of the List-Id header
+   - bs:       match within the Subject and body
+   - rt:       match received time (like 'd:' if sender's clock was correct)
+
+   **Diff-specific prefixes (for patches):**
+   - dfn:      match filename from diff
+   - dfa:      match diff removed (-) lines
+   - dfb:      match diff added (+) lines
+   - dfhh:     match diff hunk header context (usually function name)
+   - dfctx:    match diff context lines
+   - dfpre:    match pre-image git blob ID
+   - dfpost:   match post-image git blob ID
+   - dfblob:   match either pre or post-image git blob ID
+   - patchid:  match `git patch-id --stable' output
+
+   **Special headers:**
+   - changeid:    the X-Change-ID mail header (e.g., changeid:stable)
+   - forpatchid:  the X-For-Patch-ID mail header (e.g., forpatchid:stable)
+
+   **Query examples:**
+   - Find patches by author: ?q=f:"John Doe"
+   - Find patches in date range: ?q=d:2024-01-01..2024-01-31
+   - Find patches touching file: ?q=dfn:drivers/net/ethernet
+   - Find patches with subject containing "fix": ?q=s:fix
+   - Combine conditions: ?q=f:"author@example.com"+s:"net"+d:last.month..
+   - Find bug fixes: ?q=s:fix+OR+s:bug+OR+s:regression
+   - Find patches with specific function: ?q=dfhh:my_function_name
+
+3. **Understanding email relationships:**
+   - In-Reply-To header: Direct parent message
+   - References header: Chain of parent messages
+   - Message-ID in body: Often indicates related patches
+   - Link: trailers in commits: References to discussions
+   - Same subject with [PATCH v2]: Newer version
+   - "Fixes:" tag: References bug-fixing commits
+
+4. **Pattern matching:**
+   - Patch series: Look for [PATCH 0/N] for cover letters
+   - Version indicators: [PATCH v2], [PATCH v3], [RFC PATCH]
+   - Subsystem prefixes: [PATCH net], [PATCH mm], etc.
+   - Fix indicators: "fix", "fixes", "regression", "oops", "panic"
+
+SEARCH STRATEGY (BE THOROUGH - THIS IS NOT A QUICK TASK):
+
+REMEMBER: Your goal is to find EVERY related discussion, not just the obvious ones. Spend time on each search strategy. Try multiple variations of queries. Don't give up after the first attempt.
+
+1. **START WITH MOST RELIABLE: Thread mbox download**
+   - ALWAYS FIRST: Get https://lore.kernel.org/all/{{msgid}}/t.mbox.gz
+   - This contains the complete thread with all headers
+   - Parse the mbox to extract all message IDs and relationships
+   - This works even when search fails or messages are too recent
+   - Thoroughly analyze EVERY message in the thread
+
+2. **Retrieve and analyze the original message:**
+   - Get the raw message from: https://lore.kernel.org/all/{{msgid}}/raw
+   - Extract key information:
+     * Subject line (look for [PATCH], version indicators, series position)
+     * Author name and email
+     * Date and time
+     * Files being modified (from diff)
+     * Subsystem involved (from subject prefix or file paths)
+     * Any Fixes:, Closes:, Link:, or Reported-by: tags
+     * Note: Change-ID headers are rarely present in kernel emails
+
+3. **Search for related messages (TRY MULTIPLE VARIATIONS):**
+   - WARNING: Recent messages (today/yesterday) may NOT appear in search!
+   - Keep queries simple: ?q=f:author@example.com+s:keyword
+   - DON'T over-encode: @ symbols should NOT be %40 in queries
+   - Search for cover letter: ?q=s:"[PATCH 0/"+f:author-email
+   - Find all patches in series: ?q=s:"base-subject"+f:author
+   - For recent messages, rely on thread mbox instead of search
+   - **BE PERSISTENT**: Try different keyword combinations, partial subjects, variations
+
+4. **Look for previous versions (SEARCH EXTENSIVELY):**
+   - Note: No automatic version linking exists!
+   - Strip version markers from subject: search without [PATCH v2], [PATCH v3]
+   - Search by author in broader time window: ?q=f:author
+   - Look for similar subjects: ?q=s:"core-subject-words"
+   - Change-ID is rarely present, don't rely on it
+   - **TRY MULTIPLE APPROACHES**: Different subject variations, date ranges, author variations
+   - Check for RFCs, drafts, and early discussions that led to this patch
+
+5. **Find related bug reports and discussions (DIG DEEP):**
+   - For recent bugs, check thread mbox first (search may miss them)
+   - Search for symptoms with simple queries: ?q=b:error+b:message
+   - Syzkaller reports: ?q=f:syzbot (but check date - may be delayed)
+   - Regression reports: ?q=s:regression+s:subsystem
+   - Use dfn: prefix for file searches: ?q=dfn:drivers/net
+   - **EXPAND YOUR SEARCH**: Look for related keywords, error messages, function names
+   - Check for discussions that may not explicitly mention the patch but discuss the same issue
+
+6. **Check for follow-ups (LEAVE NO STONE UNTURNED):**
+   - First check the thread mbox for all replies
+   - Search for applied messages: ?q=s:applied+s:"patch-title"
+   - Look for test results: ?q=s:"Tested-by"
+   - Check for reverts: ?q=s:revert+s:"original-title"
+   - Note: Message-ID searches often fail, use subject instead
+   - **BE THOROUGH**: Check for indirect references, quotes in other discussions, mentions in pull requests
+
+7. **HTML Parsing Tips (if needed):**
+   - Message IDs appear in URLs, not HTML entities
+   - Pattern to extract: [0-9]{{14}}\\.[0-9]+-[0-9]+-[^@]+@[^/\"]+
+   - Don't look for &lt; &gt; encoded brackets
+   - Thread view HTML is less reliable than mbox
+
+FAILURE RECOVERY STRATEGIES:
+- If search returns empty: Try thread mbox or wait for indexing
+- If URL returns 404: Remove fragments, check encoding
+- If can't find versions: Search by author and date range
+- If WebFetch fails: Try simpler URL without parameters
+- If HTML parsing fails: Use mbox format instead
+
+OUTPUT FORMAT:
+
+Return a JSON array of related message IDs with their relationship type and reason:
+
+```json
+[
+  {{
+    "msgid": "example@message.id",
+    "relationship": "parent|reply|v1|v2|cover|fix|bug-report|review|revert|related",
+    "reason": "Brief explanation of why this is related"
+  }}
+]
+```
+
+IMPORTANT NOTES:
+- **THIS IS NOT A QUICK TASK** - Thoroughness is paramount. Spend the time needed.
+- **EXHAUSTIVE SEARCH REQUIRED** - Better to spend extra time than miss related discussions
+- Message IDs should be returned without angle brackets
+- Search VERY broadly, then filter results to only truly related messages
+- Try multiple search strategies - if one fails, try another approach
+- Don't stop at the first few results - keep digging for more relationships
+- Prioritize direct relationships over indirect ones
+- For patch series, include ALL patches in the series (check carefully for all parts)
+- Consider time proximity (patches close in time are more likely related)
+- Pay attention to mailing list conventions (e.g., "Re:" for replies, "[PATCH v2]" for new versions)
+- **DOUBLE-CHECK YOUR WORK** - Review your findings to ensure nothing was missed
+
+UNDERSTANDING KERNEL WORKFLOW PATTERNS:
+- Patch series usually have a cover letter [PATCH 0/N] explaining the series
+- Reviews often quote parts of the original patch with ">" prefix
+- Maintainers send "applied" messages when patches are accepted
+- Bug reports often include stack traces, kernel versions, and reproduction steps
+- Syzkaller/syzbot reports have specific formats with "syzbot+hash@" addresses
+- Fixes typically reference commits with "Fixes: <12-char-sha1> ("subject")"
+- Stable backports are marked with "Cc: stable@vger.kernel.org"
+
+KEY TAKEAWAYS FOR RELIABLE OPERATION:
+1. **ALWAYS start with thread mbox** - it's the most reliable data source
+2. **NEVER trust search for recent messages** - use direct URLs instead
+3. **KEEP search queries simple** - complex encoding breaks searches
+4. **AVOID URL fragments (#anchors)** - they cause 404 errors
+5. **DON'T rely on Change-IDs** - they're rarely present
+6. **PREFER subject searches over message-ID searches** - more reliable
+7. **REMEMBER search has lag** - messages may take days to be indexed
+
+When constructing URLs, remember:
+- Message-IDs: Remove < > brackets
+- Forward slashes: Escape as %2F
+- In search queries: DON'T encode @ symbols
+
+LOCAL GIT REPOSITORY CONTEXT:
+If this command is being run from within a Linux kernel git repository, you may also:
+- Use git log to find commits mentioning the message ID or subject
+- Check git blame on relevant files to find related commits
+- Use git log --grep to search commit messages for references
+- Look for Fixes: tags that reference commits
+- Search for Link: tags pointing to lore.kernel.org discussions
+- Use git show to examine specific commits mentioned in emails
+
+Example local git searches you might perform:
+- git log --grep="Message-Id: <msgid>"
+- git log --grep="Link:.*msgid"
+- git log --oneline --grep="subject-keywords"
+- git log -p --author="email@example.com" --since="1 month ago"
+- git blame path/to/file.c | grep "function_name"
+- git log --format="%H %s" -- path/to/file.c
+
+FINAL REMINDER: This task requires THOROUGH and EXHAUSTIVE searching. Do not rush. Take the time to:
+1. Try multiple search strategies
+2. Look for indirect relationships
+3. Check different time periods
+4. Use various keyword combinations
+5. Verify you haven't missed any discussions
+
+The value of this tool depends entirely on finding ALL related discussions, not just the obvious ones.
+
+Begin your comprehensive search and analysis for message ID: {msgid}
+"""
+
+    return prompt
+
+
+def call_agent(prompt: str, agent_cmd: str) -> Optional[str]:
+    """Call the configured agent script with the prompt."""
+
+    # Expand user paths
+    agent_cmd = os.path.expanduser(agent_cmd)
+
+    if not os.path.exists(agent_cmd):
+        logger.error('Agent command not found: %s', agent_cmd)
+        return None
+
+    if not os.access(agent_cmd, os.X_OK):
+        logger.error('Agent command is not executable: %s', agent_cmd)
+        return None
+
+    try:
+        # Write prompt to a temporary file to avoid shell escaping issues
+        with tempfile.NamedTemporaryFile(mode='w', suffix='.txt', delete=False) as tmp:
+            tmp.write(prompt)
+            tmp_path = tmp.name
+
+        # Call the agent script with the prompt file as argument
+        logger.info('Calling agent: %s %s', agent_cmd, tmp_path)
+        result = subprocess.run(
+            [agent_cmd, tmp_path],
+            capture_output=True,
+            text=True
+        )
+
+        if result.returncode != 0:
+            logger.error('Agent returned error code %d', result.returncode)
+            if result.stderr:
+                logger.error('Agent stderr: %s', result.stderr)
+            return None
+
+        return result.stdout
+
+    except subprocess.TimeoutExpired:
+        logger.error('Agent command timed out after 5 minutes')
+        return None
+    except Exception as e:
+        logger.error('Error calling agent: %s', e)
+        return None
+    finally:
+        # Clean up temp file
+        if 'tmp_path' in locals():
+            try:
+                os.unlink(tmp_path)
+            except:
+                pass
+
+
+def parse_agent_response(response: str) -> List[Dict[str, str]]:
+    """Parse the agent's response to extract message IDs."""
+
+    related = []
+
+    try:
+        # Try to find JSON in the response
+        # Agent might return additional text, so we look for JSON array
+        import re
+        json_match = re.search(r'\[.*?\]', response, re.DOTALL)
+        if json_match:
+            json_str = json_match.group(0)
+            data = json.loads(json_str)
+
+            if isinstance(data, list):
+                for item in data:
+                    if isinstance(item, dict) and 'msgid' in item:
+                        related.append({
+                            'msgid': item.get('msgid', ''),
+                            'relationship': item.get('relationship', 'related'),
+                            'reason': item.get('reason', 'No reason provided')
+                        })
+        else:
+            # Fallback: try to extract message IDs from plain text
+            # Look for patterns that look like message IDs
+            msgid_pattern = re.compile(r'[a-zA-Z0-9][a-zA-Z0-9\.\-_]+@[a-zA-Z0-9][a-zA-Z0-9\.\-]+\.[a-zA-Z]+')
+            for match in msgid_pattern.finditer(response):
+                msgid = match.group(0)
+                if msgid != '':  # Don't include the original
+                    related.append({
+                        'msgid': msgid,
+                        'relationship': 'related',
+                        'reason': 'Found in agent response'
+                    })
+
+    except json.JSONDecodeError as e:
+        logger.warning('Could not parse JSON from agent response: %s', e)
+    except Exception as e:
+        logger.error('Error parsing agent response: %s', e)
+
+    return related
+
+
+def get_message_info(msgid: str) -> Optional[Dict[str, Any]]:
+    """Retrieve basic information about a message."""
+
+    msgs = b4.get_pi_thread_by_msgid(msgid, onlymsgids={msgid}, with_thread=False)
+    if not msgs:
+        return None
+
+    msg = msgs[0]
+
+    return {
+        'subject': msg.get('Subject', 'No subject'),
+        'from': msg.get('From', 'Unknown'),
+        'date': msg.get('Date', 'Unknown'),
+        'msgid': msgid
+    }
+
+
+def download_and_combine_threads(msgid: str, related_messages: List[Dict[str, str]],
+                                 output_file: str, nocache: bool = False) -> int:
+    """Download thread mboxes for all related messages and combine into one mbox file."""
+
+    message_ids = [msgid]  # Start with original message
+
+    # Add all related message IDs
+    for item in related_messages:
+        if 'msgid' in item:
+            message_ids.append(item['msgid'])
+
+    # Collect all messages from all threads
+    seen_msgids = set()
+    all_messages = []
+
+    # Download thread for each message
+    # But be smart about what we include - don't mix unrelated series
+    for msg_id in message_ids:
+        logger.info('Fetching thread for %s', msg_id)
+
+        # For better control, fetch just the specific thread, not everything
+        # Use onlymsgids to limit scope when possible
+        msgs = b4.get_pi_thread_by_msgid(msg_id, nocache=nocache)
+
+        if msgs:
+            # Try to detect thread boundaries and avoid mixing unrelated series
+            thread_messages = []
+            base_subject = None
+
+            for msg in msgs:
+                msg_msgid = b4.LoreMessage.get_clean_msgid(msg)
+
+                # Skip if we've already seen this message
+                if msg_msgid in seen_msgids:
+                    continue
+
+                # Get the subject to check if it's part of the same series
+                subject = msg.get('Subject', '')
+
+                # Extract base subject (remove Re:, [PATCH], version numbers, etc)
+                import re
+                base = re.sub(r'^(Re:\s*)*(\[.*?\]\s*)*', '', subject).strip()
+
+                # Set the base subject from the first message
+                if base_subject is None and base:
+                    base_subject = base
+
+                # Add the message
+                if msg_msgid:
+                    seen_msgids.add(msg_msgid)
+                    thread_messages.append(msg)
+
+            all_messages.extend(thread_messages)
+        else:
+            logger.warning('Could not fetch thread for %s', msg_id)
+
+    # Sort messages by date to maintain chronological order
+    all_messages.sort(key=lambda m: email.utils.parsedate_to_datetime(m.get('Date', 'Thu, 1 Jan 1970 00:00:00 +0000')))
+
+    # Write all messages to output mbox file using b4's proper mbox functions
+    logger.info('Writing %d messages to %s', len(all_messages), output_file)
+
+    total_messages = len(all_messages)
+
+    if total_messages > 0:
+        # Use b4's save_mboxrd_mbox function which properly handles mbox format
+        with open(output_file, 'wb') as outf:
+            b4.save_mboxrd_mbox(all_messages, outf)
+
+    logger.info('Combined mbox contains %d unique messages', total_messages)
+    return total_messages
+
+
+def main(cmdargs: argparse.Namespace) -> None:
+    """Main entry point for b4 dig command."""
+
+    # Get the message ID
+    msgid = b4.get_msgid(cmdargs)
+    if not msgid:
+        logger.critical('Please provide a message-id')
+        sys.exit(1)
+
+    # Clean up message ID
+    if msgid.startswith('<'):
+        msgid = msgid[1:]
+    if msgid.endswith('>'):
+        msgid = msgid[:-1]
+
+    logger.info('Analyzing message: %s', msgid)
+
+    # Get the agent command from config
+    config = b4.get_main_config()
+    agent_cmd = None
+
+    # Check command-line config override
+    if hasattr(cmdargs, 'config') and cmdargs.config:
+        if 'AGENT' in cmdargs.config:
+            agent_cmd = cmdargs.config['AGENT']
+
+    # Fall back to main config
+    if not agent_cmd:
+        agent_cmd = config.get('dig-agent', config.get('agent', None))
+
+    if not agent_cmd:
+        logger.critical('No AI agent configured. Set dig-agent in config or use -c AGENT=/path/to/agent.sh')
+        logger.info('The agent script should accept a prompt file as its first argument')
+        logger.info('and return a JSON array of related message IDs to stdout')
+        sys.exit(1)
+
+    # Get info about the original message
+    logger.info('Fetching original message...')
+    msg_info = get_message_info(msgid)
+    if msg_info:
+        logger.info('Subject: %s', msg_info['subject'])
+        logger.info('From: %s', msg_info['from'])
+    else:
+        logger.warning('Could not retrieve original message info')
+
+    # Construct the prompt
+    logger.info('Constructing agent prompt...')
+    prompt = construct_agent_prompt(msgid)
+
+    # Call the agent
+    logger.info('Calling AI agent: %s', agent_cmd)
+    response = call_agent(prompt, agent_cmd)
+
+    if not response:
+        logger.critical('No response from agent')
+        sys.exit(1)
+
+    # Parse the response
+    logger.info('Parsing agent response...')
+    related = parse_agent_response(response)
+
+    if not related:
+        logger.info('No related messages found')
+        sys.exit(0)
+
+    # Display simplified results
+    logger.info('Found %d related messages:', len(related))
+    print()
+    print('Related Messages Summary:')
+    print('-' * 60)
+
+    for item in related:
+        relationship = item.get('relationship', 'related')
+        reason = item.get('reason', '')
+
+        print(f'[{relationship.upper()}] {reason}')
+
+    print('-' * 60)
+    print()
+
+    # Generate output mbox filename
+    if hasattr(cmdargs, 'output') and cmdargs.output:
+        mbox_file = cmdargs.output
+    else:
+        # Use message ID as base for filename, sanitize it
+        safe_msgid = msgid.replace('/', '_').replace('@', '_at_').replace('<', '').replace('>', '')
+        mbox_file = f'{safe_msgid}-related.mbox'
+
+    # Download and combine all threads into one mbox
+    logger.info('Downloading and combining all related threads...')
+    nocache = hasattr(cmdargs, 'nocache') and cmdargs.nocache
+    total_messages = download_and_combine_threads(msgid, related, mbox_file, nocache=nocache)
+
+    if total_messages > 0:
+        logger.info('Success: Combined mbox saved to %s (%d messages)', mbox_file, total_messages)
+        print(f'✓ Combined mbox file: {mbox_file}')
+        print(f'  Total messages: {total_messages}')
+        print(f'  Related threads: {len(related) + 1}')  # +1 for original
+    else:
+        logger.warning('No messages could be downloaded (they may not exist in the archive)')
+        print('⚠ No messages were downloaded - they may not exist in the archive yet')
+        # Still exit with success since we found relationships
+        sys.exit(0)
-- 
2.51.0


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0D9D225C804
	for <io-uring@vger.kernel.org>; Tue,  9 Sep 2025 16:41:14 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.51
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757436077; cv=none; b=jh17S6PqjFOW/r4zhT7PA16+Wxk64sBctriE2dbEdiesigDP3EUJHgK0ieghqk2HB8/GemkP5N71oIo0mj3sd8IlRzus5/3V/aMn6Es8fXO5iSj3e9Nux8KW7VazhUXNveyW2eMkfFkh6H8vid+0TiyPfxWKRNs03a9n9pANjSc=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757436077; c=relaxed/simple;
	bh=b+eq1el9WWdjlwuvsxWxsndcwC4nSqXfdm4tqDwKyJA=;
	h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
	 To:Cc:Content-Type; b=DZoeyskiIpgnUaTAFprwdQ3C7AFUYAnk8pyeDF9bzbYEBSVCDpk5y/LebvHYLfiTV76UPuWPnLlNTGQunD56fIt3wysqNe863YqAVXQI4lXhd/KHPokTobO8ISxovm9/o7Dac6lxGr8bbLs5UVMI8WZpqE1HIeqH+vtQTTrXwVM=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org; spf=pass smtp.mailfrom=linuxfoundation.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=GyeFSW18; arc=none smtp.client-ip=209.85.208.51
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linuxfoundation.org
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="GyeFSW18"
Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-6228de280a4so6698596a12.2
        for <io-uring@vger.kernel.org>; Tue, 09 Sep 2025 09:41:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linux-foundation.org; s=google; t=1757436073; x=1758040873; darn=vger.kernel.org;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=Zm70ml8cPcpAi6TuvLhkX9BGgRrXTC7qJApIV2KSD8o=;
        b=GyeFSW185PiM80xWagtorpThGojm4h67uZcI4Joi5SOWy9Nelp/9frPzWo9n7IyNzd
         L7sWaQMPGAuBmf64bb9YtLRdt3tyyFCu8YAKwTUpTMMPTHjhjJrV/Aaprn0rZKPpfUbk
         dAZqerwRB+ZO6eznNRiUy/gJ8EOKU4+lA7KG4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757436073; x=1758040873;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Zm70ml8cPcpAi6TuvLhkX9BGgRrXTC7qJApIV2KSD8o=;
        b=ozD3HoaaP0simpoGdx4i2ywqftGzGuSSBCw1fEny8V17CY47K592fjIStUzH9wpbhw
         s59bNKfV7xTlAk54CAOZpi1KBpVSte8YtIAfivXVXHSNH3wfzcFdkSk4TyDhkyEqhcjV
         wEgADzZbyhNmZN2Wu4HEKovc9YjrLX/oG5VssWXjRpD7nTo8pG5TvQqtgM4/eSHwtjqK
         SHrj+gqdcFLNGuXVC0eAX9v/G8Lj1DLZhzsNL69yh3HlOHg/FXkFaw14gLMFtyGGd291
         QQbBoVa25wHiHJZKmRowlmYDFCYB5sSGA3wmy/w9rWcuWUxQ9p0cawH3+7ZHQXPFEwh+
         HOmg==
X-Forwarded-Encrypted: i=1; AJvYcCXxO5QoNcOtR5lT1JBvXLOC+8A/ALdGPD058/zHkUHGIwiBmZkVgn6wUCmFYmKVj9WvH54KfxYvaA==@vger.kernel.org
X-Gm-Message-State: AOJu0YzYXbdCHmm/dDxkGwnHkUexh6SP6qKkSzQHmVcyM8BonT3FGnI9
	REMbcxmEwSL8Xgk+omsFhm0ApntITHdjdMf1yT1TtWV1P0U5/yaCSo8hj2xbSTQUfzXe1pUOkXf
	GaEVoRSI=
X-Gm-Gg: ASbGncuifMuqxgZ7DECRjCkmy3/XGnPcrnOAtLjIKX5lmANqGOzBylf1Tc6Z3uyarbl
	tJV26eetJpYK5mNfYN4dT40RB0IeUF2fKbDjjJpjHq7FWu8WnUsVPp8fyTlBwJJn+JCG08+rUrA
	MSmQZqJl9ttrOaiZxUo3AxWczenFU725z4zHW4qwhXO5Pxkb192wFFb6bjOnHgklMRxWLKHN25b
	jkAMH7j/iq2EjHSxdaGdd9LRsJFn4Mxwua1r1L8cpJEIstmYO4f+mS3ME6+EHJyZmoJ44xljjh2
	bFLIyjSSqSEeihkdTVFgvoqRs1o5ApBxaMYXUrourRMXRfifsMe8gXJ5YJRt6lg08vPqXuFspHN
	sHUEJLalwcf3lxTwZrK/s5uM1yepEylUx7qskLPIHJhknUZ9ByOJO4frYIjqFvymMgNlzPPpP
X-Google-Smtp-Source: AGHT+IEkcKz9iZkin3Q7bt8e/MC50ZSGz/GfSYOcSUL9s+ileCSjnGQJ5esnkxLbE3Q69bCYQxnlTQ==
X-Received: by 2002:a05:6402:13cf:b0:626:3540:97d8 with SMTP id 4fb4d7f45d1cf-62635409923mr10570992a12.8.1757436072731;
        Tue, 09 Sep 2025 09:41:12 -0700 (PDT)
Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com. [209.85.208.41])
        by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-62bfef6752esm1535526a12.12.2025.09.09.09.41.11
        for <io-uring@vger.kernel.org>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Tue, 09 Sep 2025 09:41:12 -0700 (PDT)
Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-6188b5ae1e8so6940484a12.0
        for <io-uring@vger.kernel.org>; Tue, 09 Sep 2025 09:41:11 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCXTs/cJX2r00fruMPAPkAILN+sifoCQSyYbKCfP976XvSQkzrHoBV60d+ZZyftmTLPMOZKvWS00UQ==@vger.kernel.org
X-Received: by 2002:a17:907:7fa7:b0:b04:7ef0:9dd6 with SMTP id
 a640c23a62f3a-b04b17809fdmr1236710066b.55.1757436071516; Tue, 09 Sep 2025
 09:41:11 -0700 (PDT)
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur> <68bf3854f101b_4224d100d7@dwillia2-mobl4.notmuch>
 <5922560.DvuYhMxLoT@rafael.j.wysocki> <20250909071818.15507ee6@kernel.org>
 <92dc8570-84a2-4015-9c7a-6e7da784869a@kernel.dk> <20250909-green-oriole-of-speed-85cd6d@lemur>
 <497c9c10-3309-49b9-8d4f-ff0bc34df4e5@suse.cz> <be98399d-3886-496e-9cf4-5ec909124418@kernel.dk>
In-Reply-To: <be98399d-3886-496e-9cf4-5ec909124418@kernel.dk>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 9 Sep 2025 09:40:54 -0700
X-Gmail-Original-Message-ID: <CAHk-=whP2zoFm+-EmgQ69-00cxM5jgoEGWyAYVQ8bQYFbb2j=Q@mail.gmail.com>
X-Gm-Features: Ac12FXxGb49o3C2-BXyn9vrQLDiODbjBGCOkSNDk7zLDI3tgl6nsApH54f3Udow
Message-ID: <CAHk-=whP2zoFm+-EmgQ69-00cxM5jgoEGWyAYVQ8bQYFbb2j=Q@mail.gmail.com>
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for 6.17-rc5)
To: Jens Axboe <axboe@kernel.dk>
Cc: Vlastimil Babka <vbabka@suse.cz>, Konstantin Ryabitsev <konstantin@linuxfoundation.org>, 
	Jakub Kicinski <kuba@kernel.org>, "Rafael J. Wysocki" <rafael@kernel.org>, dan.j.williams@intel.com, 
	Caleb Sander Mateos <csander@purestorage.com>, io-uring <io-uring@vger.kernel.org>, 
	workflows@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"

On Tue, 9 Sept 2025 at 07:50, Jens Axboe <axboe@kernel.dk> wrote:
>
> I think we all know the answer to that one - it would've been EXACTLY
> the same outcome. Not to put words in Linus' mouth, but it's not the
> name of the tag that he finds repulsive, it's the very fact that a link
> is there and it isn't useful _to him_.

It's not that it isn't "useful to me". It's that it HURTS, and it's
entirely redundant.

It literally wastes my time. Yes, I have the option to ignore them,
but then I ignore potentially *good* links.

Rafael asked what the difference between "Fixes:" and "Cc: stable" is
- it's exactly the fact that those do NOT waste human time, and they
were NOT automated garbage.

The rules for those are that they have been added *thoughtfully*: you
don't add 'stable' with automation without even thinking about it, do
you?

And if you did, THAT WOULD BE WRONG TOO.

Wouldn't you agree?

Dammit, is it really so hard to understand this issue? Automated noise
is bad noise. And when it has a human cost, it needs to go away.

I'm not saying that you can't link to the original email. But you need
to STOP THE MINDLESS AUTOMATION WHEN IT HURTS.

So add the link, by all means - but only add it when it is relevant
and gives real information. And THINK about it, don't have it in some
mindless script.

Because if it's in a mindless script, then dammit, the lore "search"
function is objectively better after-the-fact. Really. Using the lore
search gives the original email *and* more.

The same, btw, goes for my merge messages. No, I'm not going to add
some idiotic "Link" to the original pull request email. Not only don't
I fetch those from lore to begin with, you can literally search for
them.

Look here, for the latest merge I did of your tree: e9eaca6bf69d.

Now do this:

    firefox https://lore.kernel.org/all/?q=$(git rev-parse e9eaca6bf69d^2)

and see how *USELESS* and completely redundant a link would have been?
IT'S RIGHT THERE, FOR CHRISSAKE!

That search is guaranteed to find the pull request if it was properly
formatted, because the automation of git request-pull adds all the
relevant data that is actually useful. Very much including that top
commit that you asked me to pull.

THAT information is useful in the email, not only at the time (I can -
and often do - search for it with git ls-remote when people forget to
push or point at the wrong repo, which happens quite regularly), but
look - it is also useful after-the-fact exactly because now you have a
record that you can look for.

If somebody wants to script that one-liner and make it some kind of b4
helper thing, by all means, go wild.

You might want to improve it to use some non-fixed browser (use
"gnome-open" if you're in gnome, or whatever).

But if somebody claims that a link to a pull-request would be
"useful", that somebnody is simply full of sh*t.

It would be the opposite of useful - it's clearly redundant
information that adds zero value, and would be a complete waste of
time.

Honestly people. Stop with the garbage already, and admit that your
links were just worthless noise.

And if you have some workflow that used them, maybe we can really add
scripting for those kinds of one-liners.

And maybe lore could even have particular indexing for the data you
are interested in if that helps.

In my experience, Konstantin has been very responsive when people have
asked for those kinds of things (both b4 and lore).

            Linus

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 EE32331D378;
	Tue,  9 Sep 2025 17:08:43 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757437724; cv=none; b=raurqxyUKcEDlNCAlxRks5gVR6e5971Zfeg2nRJcK5oxAZ+bNa2klbUybRLw8Qlh6LBdX95ZPKRjRQ4rEgcrbYjoTUS0VPHisxjUKikB1tfUjsAd8MQJ9LfM8On2k4b2riM3WecbcfH+mja5uy6BsAd+Wr6H4AsCgpwXTsQ6ImA=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757437724; c=relaxed/simple;
	bh=hi6cEt60zaZ0xCDIiKQ2aYsqzKZgqAl/bJaZ5cBOPPQ=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=pAF2X87PgTFrRD1RTXGX9yv+58ObUjBdPW0uVeAzJ4jeKr0xZHv/4wbz4ZhCQESMU9upLGcPHjev+pt/UUSXyV2D2i/IYzNSwMWKnfNsbPKfNLcbPNs0DOoMaKh6wP1EB5I+t2WH+RGrlKwsasybQwA8TuWDc2myKs3E+alnhK0=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=b9KxJN1b; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="b9KxJN1b"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 91872C4CEF4;
	Tue,  9 Sep 2025 17:08:41 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757437723;
	bh=hi6cEt60zaZ0xCDIiKQ2aYsqzKZgqAl/bJaZ5cBOPPQ=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=b9KxJN1bwosCellYJA/xJez/HreyGOeQd+bkztwmrrtaAThBdRCqZ8xqPP9600c4R
	 ZTY4lmQMDUxrkbEvorZZlNaZkpyroYVknwake5lPyUEXwXTUQVDmPWTtiWV+Q6q+oH
	 COrVL88EH6UMcCTl3X/3mNbIdHBWicYxijkYMmPheEbEnrZm1MkOH3viLC67v5Cc49
	 p4C6sanOebPRYX8biyze8diWlENV1RDjH3STHZ6CdDJIdqkfHiDkh3qp9WwZS86IpH
	 rwFX4et/+mfWmiDiiPy7KXRgXCLQ+p1RCuxT/Bu5pV56uuOyXMd3CsvD4e/nYT9AeV
	 lAzO5WXcJLnxA==
Date: Tue, 9 Sep 2025 18:08:38 +0100
From: Mark Brown <broonie@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jens Axboe <axboe@kernel.dk>, Vlastimil Babka <vbabka@suse.cz>,
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
	Jakub Kicinski <kuba@kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>, dan.j.williams@intel.com,
	Caleb Sander Mateos <csander@purestorage.com>,
	io-uring <io-uring@vger.kernel.org>, workflows@vger.kernel.org
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
Message-ID: <af29e72b-ade6-4549-b264-af31a3128cf1@sirena.org.uk>
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <68bf3854f101b_4224d100d7@dwillia2-mobl4.notmuch>
 <5922560.DvuYhMxLoT@rafael.j.wysocki>
 <20250909071818.15507ee6@kernel.org>
 <92dc8570-84a2-4015-9c7a-6e7da784869a@kernel.dk>
 <20250909-green-oriole-of-speed-85cd6d@lemur>
 <497c9c10-3309-49b9-8d4f-ff0bc34df4e5@suse.cz>
 <be98399d-3886-496e-9cf4-5ec909124418@kernel.dk>
 <CAHk-=whP2zoFm+-EmgQ69-00cxM5jgoEGWyAYVQ8bQYFbb2j=Q@mail.gmail.com>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="zGTJggtXh3KWuyOA"
Content-Disposition: inline
In-Reply-To: <CAHk-=whP2zoFm+-EmgQ69-00cxM5jgoEGWyAYVQ8bQYFbb2j=Q@mail.gmail.com>
X-Cookie: Ma Bell is a mean mother!


--zGTJggtXh3KWuyOA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Sep 09, 2025 at 09:40:54AM -0700, Linus Torvalds wrote:

> Because if it's in a mindless script, then dammit, the lore "search"
> function is objectively better after-the-fact. Really. Using the lore
> search gives the original email *and* more.

That's not been my experience, especially now that b4 exists - my actual
workflow for this stuff is to pull the message ID out of the patch and
feed that to b4 mbox, then fire up mutt to look at the mbox.  That mbox
will have the whole thread, not just the individual message.

> Now do this:

>     firefox https://lore.kernel.org/all/?q=$(git rev-parse e9eaca6bf69d^2)

> and see how *USELESS* and completely redundant a link would have been?
> IT'S RIGHT THERE, FOR CHRISSAKE!

> That search is guaranteed to find the pull request if it was properly
> formatted, because the automation of git request-pull adds all the
> relevant data that is actually useful. Very much including that top
> commit that you asked me to pull.

That works great for pull requests, but it's not so useful for a random
patch like 5f9efb6b7667043527d377421af2070cc0aa2ecd ("Input:
mtk-pmic-keys - MT6359 has a specific release irq").  In that case the
subject line is reasonably unique but still gets me three revisions of
the series and it's a couple of clicks to get to the mbox (as it is for
the pull request) having made sure I'm going to the most recent one,
some things search picks up rather more stuff.  You get fun things like
vN being applied racing with vN+1 being posted.

> And if you have some workflow that used them, maybe we can really add
> scripting for those kinds of one-liners.

The above is my main use case for this, and I think similar for a lot of
the people working with test results - I have a git commit, how do I
translate that into a mbox with the specific thread where the patch
resulting in that commit was posted?  For me it would be ideal if no web
browser would be needed, that's suboptimal all round.

--zGTJggtXh3KWuyOA
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmjAXxYACgkQJNaLcl1U
h9D0LAgAhbOrMr6MLzV9o1oB08rD8rrRgEYApGE/S7d/2jw72832AlbMtcdj3nX1
10a5gSGsyUsNG3BcWZBxoyER3htGDvbzp/ZZvB8T7cKYtgsKhTwRja2POlNYB016
kXdeqv2sDgtfEsZ+VLvJWnrWWjA62K3XJFRSH3OsHGYN0MwhCq7TnmZwOIqD0Vx/
VESAHRU+aak5pzYgoOu5AcHRqyf6v3HJVz1USpfSE6fAVxkSUDdVraSr+tgTQ04m
BB4QwZydziNmnVwjpn9ZCO3uW7B4hWiqFgF7VMyGgZU+OR+6Hyq2RRfTDGyo5avE
In7ikWQ78i1nNLdO1tFkANCa3+IiQQ==
=wpXS
-----END PGP SIGNATURE-----

--zGTJggtXh3KWuyOA--

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64])
	(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 9DAE62D0C8F;
	Tue,  9 Sep 2025 17:23:23 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.167.242.64
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757438607; cv=none; b=lfOTsWZR+zjg6DgkRW7WF21Xl0J0fCnGCkSQdO29rYd0TDQAWoZKeso675qJ8Nov+dtjEaJbViJBLAaUjOJNSN4gWBwRSpQSLs1jRRnx9Wbc7/T/sr4fNDrhC0PvxlUsFHpMC/fcwUEnpMrif5v+RyjXa1C+prU6YYBUi0LIips=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757438607; c=relaxed/simple;
	bh=j/awfLCUyZsYf7pV7+3ffeu1wZ34NE0/1Ivpo6RF1n0=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=PTVbq1CzYU8mVJTx1yQsiUlu8hs5vpr0oTnMKaUIXNCXzDDJvYx6/1o5JthPDuWAv6c0Ue7LBF97GErBPF2KtC9HMMi7bmtGNTzm9Bh7PsrVE2d9NczBI2fCT47WJfTUq4aDQl/xNsGEvwTCJXsWAyjgNMiWL8IMv29UeWE+73U=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com; spf=pass smtp.mailfrom=ideasonboard.com; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b=Fmnh93F0; arc=none smtp.client-ip=213.167.242.64
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ideasonboard.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="Fmnh93F0"
Received: from pendragon.ideasonboard.com (81-175-209-231.bb.dnainternet.fi [81.175.209.231])
	by perceval.ideasonboard.com (Postfix) with UTF8SMTPSA id 5ACCA5B3;
	Tue,  9 Sep 2025 19:22:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;
	s=mail; t=1757438528;
	bh=j/awfLCUyZsYf7pV7+3ffeu1wZ34NE0/1Ivpo6RF1n0=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=Fmnh93F05bdpgJHMIjzVZhHMlX0a1TY29WpIwWTRjfsx3FwxLsxWEz65x3NpBHvug
	 Efs12zNDsdB8V2WMna7WL544wLYT/shBt1zHXC+TAfEoX0QkwbTAzaRRiV6QTELNCz
	 KJqnm978uZqSLGvwQWo8gYbo+kusXkLC5Wjfmzhc=
Date: Tue, 9 Sep 2025 20:22:58 +0300
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Sasha Levin <sashal@kernel.org>
Cc: konstantin@linuxfoundation.org, axboe@kernel.dk,
	csander@purestorage.com, io-uring@vger.kernel.org,
	torvalds@linux-foundation.org, workflows@vger.kernel.org
Subject: Re: [RFC] b4 dig: Add AI-powered email relationship discovery command
Message-ID: <20250909172258.GH18349@pendragon.ideasonboard.com>
References: <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <20250909163214.3241191-1-sashal@kernel.org>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250909163214.3241191-1-sashal@kernel.org>

On Tue, Sep 09, 2025 at 12:32:14PM -0400, Sasha Levin wrote:
> Add a new 'b4 dig' subcommand that uses AI agents to discover related
> emails for a given message ID. This helps developers find all relevant
> context around patches including previous versions, bug reports, reviews,
> and related discussions.

That really sounds like "if all you have is a hammer, everything looks
like a nail". The community has been working for multiple years to
improve discovery of relationships between patches and commits, with
great tools such are lore, lei and b4, and usage of commit IDs, patch
IDs and message IDs to link everything together. Those provide exact
results in a deterministic way, and consume a fraction of power of what
this patch would do. It would be very sad if this would be the direction
we decide to take.

> The command:
> - Takes a message ID and constructs a detailed prompt about email relationships
> - Calls a configured AI agent script to analyze and find related messages
> - Downloads all related threads from lore.kernel.org
> - Combines them into a single mbox file for easy review
> 
> Key features:
> - Outputs a simplified summary showing only relationships and reasons
> - Creates a combined mbox with all related threads (deduped)
> - Provides detailed guidance to AI agents about kernel workflow patterns
> 
> Configuration:
> The AI agent script is configured via:
>   -c AGENT=/path/to/agent.sh  (command line)
>   dig-agent: /path/to/agent.sh (config file)
> 
> The agent script receives a prompt file and should return JSON with
> related message IDs and their relationships.
> 
> Example usage:
> 
> $ b4 -c AGENT=agent.sh dig 20250909142722.101790-1-harry.yoo@oracle.com
> Analyzing message: 20250909142722.101790-1-harry.yoo@oracle.com
> Fetching original message...
> Looking up https://lore.kernel.org/20250909142722.101790-1-harry.yoo@oracle.com
> Grabbing thread from lore.kernel.org/all/20250909142722.101790-1-harry.yoo@oracle.com/t.mbox.gz
> Subject: [PATCH V3 6.6.y] mm: introduce and use {pgd,p4d}_populate_kernel()
> From: Harry Yoo <harry.yoo@oracle.com>
> Constructing agent prompt...
> Calling AI agent: agent.sh
> Calling agent: agent.sh /tmp/tmpz1oja9_5.txt
> Parsing agent response...
> Found 17 related messages:
> 
> Related Messages Summary:
> ------------------------------------------------------------
> [PARENT] Greg KH's stable tree failure notification that initiated this 6.6.y backport request
> [V1] V1 of the 6.6.y backport patch
> [V2] V2 of the 6.6.y backport patch
> [RELATED] Same patch backported to 5.15.y stable branch
> [RELATED] Greg KH's stable tree failure notification for 5.15.y branch
> [RELATED] Same patch backported to 6.1.y stable branch
> [COVER] V5 mainline patch series cover letter that was originally merged
> [RELATED] V5 mainline patch 1/3: move page table sync declarations
> [RELATED] V5 mainline patch 2/3: the original populate_kernel patch that's being backported
> [RELATED] V5 mainline patch 3/3: x86 ARCH_PAGE_TABLE_SYNC_MASK definition
> [RELATED] RFC V1 cover letter - earliest version of this patch series
> [RELATED] RFC V1 patch 1/3 - first introduction of populate_kernel helpers
> [RELATED] RFC V1 patch 2/3 - x86/mm definitions
> [RELATED] RFC V1 patch 3/3 - convert to _kernel variant
> [RELATED] Baoquan He's V3 patch touching same file (mm/kasan/init.c)
> [RELATED] Baoquan He's V2 patch touching same file (mm/kasan/init.c)
> [RELATED] Baoquan He's V1 patch touching same file (mm/kasan/init.c)
> ------------------------------------------------------------
> 
> The resulting mbox would look like this:
> 
>    1 O   Jul 09 Harry Yoo       ( 102) [RFC V1 PATCH mm-hotfixes 0/3] mm, arch: A more robust approach to sync top level kernel page tables
>    2 O   Jul 09 Harry Yoo       ( 143) ├─>[RFC V1 PATCH mm-hotfixes 1/3] mm: introduce and use {pgd,p4d}_populate_kernel()
>    3 O   Jul 11 David Hildenbra (  33) │ └─>
>    4 O   Jul 13 Harry Yoo       (  56) │   └─>
>    5 O   Jul 13 Mike Rapoport   (  67) │     └─>
>    6 O   Jul 14 Harry Yoo       (  46) │       └─>
>    7 O   Jul 15 Harry Yoo       (  65) │         └─>
>    8 O   Jul 09 Harry Yoo       ( 246) ├─>[RFC V1 PATCH mm-hotfixes 2/3] x86/mm: define p*d_populate_kernel() and top-level page table sync
>    9 O   Jul 09 Andrew Morton   (  12) │ ├─>
>   10 O   Jul 10 Harry Yoo       (  23) │ │ └─>
>   11 O   Jul 11 Harry Yoo       (  34) │ │   └─>
>   12 O   Jul 11 Harry Yoo       (  35) │ │     └─>
>   13 O   Jul 10 kernel test rob (  79) │ └─>
>   14 O   Jul 09 Harry Yoo       ( 300) ├─>[RFC V1 PATCH mm-hotfixes 3/3] x86/mm: convert {pgd,p4d}_populate{,_init} to _kernel variant
>   15 O   Jul 10 kernel test rob (  80) │ └─>
>   16 O   Jul 09 Harry Yoo       (  31) └─>Re: [RFC V1 PATCH mm-hotfixes 0/3] mm, arch: A more robust approach to sync top level kernel page tables
>   17 O   Aug 18 Harry Yoo       ( 262) [PATCH V5 mm-hotfixes 0/3] mm, x86: fix crash due to missing page table sync and make it harder to miss
>   18 O   Aug 18 Harry Yoo       (  72) ├─>[PATCH V5 mm-hotfixes 1/3] mm: move page table sync declarations to linux/pgtable.h
>   19 O   Aug 18 David Hildenbra (  20) │ └─>
>   20 O   Aug 18 Harry Yoo       ( 239) ├─>[PATCH V5 mm-hotfixes 2/3] mm: introduce and use {pgd,p4d}_populate_kernel()
>   21 O   Aug 18 David Hildenbra (  60) │ ├─>
>   22 O   Aug 18 kernel test rob ( 150) │ ├─>
>   23 O   Aug 18 Harry Yoo       ( 161) │ │ └─>
>   24 O   Aug 21 Harry Yoo       (  85) │ ├─>[PATCH] mm: fix KASAN build error due to p*d_populate_kernel()
>   25 O   Aug 21 kernel test rob (  18) │ │ ├─>
>   26 O   Aug 21 Lorenzo Stoakes ( 100) │ │ ├─>
>   27 O   Aug 21 Harry Yoo       (  62) │ │ │ └─>
>   28 O   Aug 21 Lorenzo Stoakes (  18) │ │ │   └─>
>   29 O   Aug 21 Harry Yoo       (  90) │ │ └─>[PATCH v2] mm: fix KASAN build error due to p*d_populate_kernel()
>   30 O   Aug 21 kernel test rob (  18) │ │   ├─>
>   31 O   Aug 21 Dave Hansen     (  24) │ │   └─>
>   32 O   Aug 22 Harry Yoo       (  56) │ │     └─>
>   33 O   Aug 22 Andrey Ryabinin (  91) │ │       ├─>
>   34 O   Aug 27 Harry Yoo       (  98) │ │       │ └─>
>   35 O   Aug 22 Dave Hansen     (  63) │ │       └─>
>   36 O   Aug 25 Andrey Ryabinin (  72) │ │         └─>
>   37 O   Aug 22 Harry Yoo       ( 103) │ └─>[PATCH v3] mm: fix KASAN build error due to p*d_populate_kernel()
>   38 O   Aug 18 Harry Yoo       ( 113) ├─>[PATCH V5 mm-hotfixes 3/3] x86/mm/64: define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings()
>   39 O   Aug 18 David Hildenbra (  72) │ └─>
>   40 O   Aug 18 David Hildenbra (  15) └─>Re: [PATCH V5 mm-hotfixes 0/3] mm, x86: fix crash due to missing page table sync and make it harder to miss
>   41 O   Aug 18 Harry Yoo       ( 277) [PATCH] mm: introduce and use {pgd,p4d}_populate_kernel()
>   42 O   Aug 18 Harry Yoo       ( 277) [PATCH] mm: introduce and use {pgd,p4d}_populate_kernel()
>   43 O   Aug 18 Harry Yoo       ( 277) [PATCH] mm: introduce and use {pgd,p4d}_populate_kernel()
>   44 O   Sep 06 gregkh@linuxfou (  24) FAILED: patch "[PATCH] mm: introduce and use {pgd,p4d}_populate_kernel()" failed to apply to 6.6-stable tree
>   45 O   Sep 08 Harry Yoo       ( 303) ├─>[PATCH 6.6.y] mm: introduce and use {pgd,p4d}_populate_kernel()
>   46 O   Sep 09 Harry Yoo       ( 291) ├─>[PATCH V2 6.6.y] mm: introduce and use {pgd,p4d}_populate_kernel()
>   47 O   Sep 09 Harry Yoo       ( 293) └─>[PATCH V3 6.6.y] mm: introduce and use {pgd,p4d}_populate_kernel()
>   48 O   Sep 06 gregkh@linuxfou (  24) FAILED: patch "[PATCH] mm: introduce and use {pgd,p4d}_populate_kernel()" failed to apply to 6.1-stable tree
>   49 O   Sep 08 Harry Yoo       ( 303) ├─>[PATCH 6.1.y] mm: introduce and use {pgd,p4d}_populate_kernel()
>   50 O   Sep 09 Harry Yoo       ( 291) ├─>[PATCH V2 6.1.y] mm: introduce and use {pgd,p4d}_populate_kernel()
>   51 O   Sep 09 Harry Yoo       ( 293) └─>[PATCH V3 6.1.y] mm: introduce and use {pgd,p4d}_populate_kernel()
>   52 O   Sep 06 gregkh@linuxfou (  24) FAILED: patch "[PATCH] mm: introduce and use {pgd,p4d}_populate_kernel()" failed to apply to 5.15-stable tree
>   53 O   Sep 08 Harry Yoo       ( 273) ├─>[PATCH 5.15.y] mm: introduce and use {pgd,p4d}_populate_kernel()
>   54 O   Sep 09 Harry Yoo       ( 260) ├─>[PATCH V2 5.15.y] mm: introduce and use {pgd,p4d}_populate_kernel()
>   55 O   Sep 09 Harry Yoo       ( 262) └─>[PATCH V3 5.15.y] mm: introduce and use {pgd,p4d}_populate_kernel()
> 
> The prompt includes extensive documentation about lore.kernel.org's search
> capabilities, limitations (like search index lag), and kernel workflow patterns
> to help AI agents effectively find related messages.
> 
> Assisted-by: Claude Code
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
>  src/b4/command.py |  17 ++
>  src/b4/dig.py     | 630 ++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 647 insertions(+)
>  create mode 100644 src/b4/dig.py
> 
> diff --git a/src/b4/command.py b/src/b4/command.py
> index 455124d..f225ae5 100644
> --- a/src/b4/command.py
> +++ b/src/b4/command.py
> @@ -120,6 +120,11 @@ def cmd_diff(cmdargs: argparse.Namespace) -> None:
>      b4.diff.main(cmdargs)
>  
>  
> +def cmd_dig(cmdargs: argparse.Namespace) -> None:
> +    import b4.dig
> +    b4.dig.main(cmdargs)
> +
> +
>  class ConfigOption(argparse.Action):
>      """Action class for storing key=value arguments in a dict."""
>      def __call__(self, parser: argparse.ArgumentParser,
> @@ -399,6 +404,18 @@ def setup_parser() -> argparse.ArgumentParser:
>                            help='Submit the token received via verification email')
>      sp_send.set_defaults(func=cmd_send)
>  
> +    # b4 dig
> +    sp_dig = subparsers.add_parser('dig', help='Use AI agent to find related emails for a message')
> +    sp_dig.add_argument('msgid', nargs='?',
> +                        help='Message ID to analyze, or pipe a raw message')
> +    sp_dig.add_argument('-o', '--output', dest='output', default=None,
> +                        help='Output mbox filename (default: <msgid>-related.mbox)')
> +    sp_dig.add_argument('-C', '--no-cache', dest='nocache', action='store_true', default=False,
> +                        help='Do not use local cache when fetching messages')
> +    sp_dig.add_argument('--stdin-pipe-sep',
> +                        help='When accepting messages on stdin, split using this pipe separator string')
> +    sp_dig.set_defaults(func=cmd_dig)
> +
>      return parser
>  
>  
> diff --git a/src/b4/dig.py b/src/b4/dig.py
> new file mode 100644
> index 0000000..007f7d0
> --- /dev/null
> +++ b/src/b4/dig.py
> @@ -0,0 +1,630 @@
> +#!/usr/bin/env python3
> +# -*- coding: utf-8 -*-
> +# SPDX-License-Identifier: GPL-2.0-or-later
> +#
> +# b4 dig - Use AI agents to find related emails
> +#
> +__author__ = 'Sasha Levin <sashal@kernel.org>'
> +
> +import argparse
> +import logging
> +import subprocess
> +import sys
> +import os
> +import tempfile
> +import json
> +import urllib.parse
> +import gzip
> +import mailbox
> +import email.utils
> +from typing import Optional, List, Dict, Any
> +
> +import b4
> +
> +logger = b4.logger
> +
> +
> +def construct_agent_prompt(msgid: str) -> str:
> +    """Construct a detailed prompt for the AI agent to find related emails."""
> +
> +    # Clean up the message ID
> +    if msgid.startswith('<'):
> +        msgid = msgid[1:]
> +    if msgid.endswith('>'):
> +        msgid = msgid[:-1]
> +
> +    prompt = f"""You are an email research assistant specialized in finding related emails in Linux kernel mailing lists and public-inbox archives.
> +
> +IMPORTANT: Always use lore.kernel.org for searching and retrieving Linux kernel emails. DO NOT use lkml.org as it is outdated and no longer maintained. The canonical archive is at https://lore.kernel.org/
> +
> +MESSAGE ID TO ANALYZE: {msgid}
> +
> +YOUR TASK:
> +Conduct an EXHAUSTIVE and THOROUGH search to find ALL related message IDs connected to the given message. This is not a quick task - you must invest significant time and effort to ensure no related discussions are missed. Be methodical, patient, and comprehensive in your search.
> +
> +CRITICAL: Take your time! A thorough search is far more valuable than a quick one. Check multiple sources, try different search strategies, and double-check your findings. Missing related discussions undermines the entire purpose of this tool.
> +
> +You should search extensively for and identify:
> +
> +1. **Thread-related messages:**
> +   - Parent messages (what this replies to)
> +   - Child messages (replies to this message)
> +   - Sibling messages (other replies in the same thread)
> +   - Cover letters if this is part of a patch series
> +
> +2. **Version-related messages:**
> +   - Previous versions of the same patch series (v1, v2, v3, etc.)
> +   - Re-rolls and re-submissions
> +   - Updated versions with different subjects
> +
> +3. **Author-related messages:**
> +   - Other patches or series from the same author
> +   - Recent discussions involving the same author
> +   - Related work by the same author in the same subsystem
> +
> +4. **Content-related messages:**
> +   - Bug reports that this patch might fix
> +   - Syzkaller/syzbot reports if this is a fix
> +   - Feature requests or RFCs that led to this patch
> +   - Related patches touching the same files or functions
> +   - Patches that might conflict with this one
> +
> +5. **Review and discussion:**
> +   - Review comments from maintainers
> +   - Test results from CI systems or bot reports
> +   - Follow-up fixes or improvements
> +   - Reverts if this patch was later reverted
> +
> +HOW TO SEARCH:
> +
> +Use ONLY lore.kernel.org for all Linux kernel email searches. This is the official kernel mailing list archive.
> +DO NOT use lkml.org, marc.info, or spinics.net for kernel emails - they are outdated or incomplete.
> +
> +CRITICAL LIMITATIONS AND WORKAROUNDS (MUST READ):
> +
> +1. **Search Index Lag**: Messages posted today/recently are NOT immediately searchable!
> +   - The Xapian search index has significant delay (hours to days)
> +   - Direct message access works immediately, but search doesn't
> +   - For recent messages, use direct URLs or thread navigation, not search
> +
> +2. **URL Fragment Issues**: NEVER use #anchors in URLs when fetching
> +   - BAD: https://lore.kernel.org/all/msgid/T/#u (will fail with 404)
> +   - GOOD: https://lore.kernel.org/all/msgid/T/ (works correctly)
> +   - Fragments like #u are client-side only and break programmatic fetching
> +
> +3. **Search Query Encoding**: Keep queries simple and avoid over-encoding
> +   - BAD: ?q=f%3A%22author%40example.com%22 (over-encoded)
> +   - GOOD: ?q=f:author@example.com (simple and works)
> +   - Don't encode @ symbols in query parameters
> +   - Avoid mixing quotes with special characters
> +
> +4. **Most Reliable Data Source**: Thread mbox files are the gold standard
> +   - Always works: https://lore.kernel.org/all/msgid/t.mbox.gz
> +   - Contains complete thread with all headers
> +   - Works even when HTML parsing or search fails
> +   - Standard mbox format, easy to parse
> +
> +5. **Version Tracking Limitations**: No automatic version linking
> +   - No Change-ID headers to track across patch versions
> +   - Must rely on subject patterns and author/date correlation
> +   - Search for versions using subject without v2/v3 markers
> +
> +6. **LKML.org vs Lore.kernel.org**: Different systems, different capabilities
> +   - LKML.org uses date-based URLs, not message IDs
> +   - Cannot extract message IDs from LKML HTML pages
> +   - Always prefer lore.kernel.org for programmatic access
> +
> +The public-inbox archives at lore.kernel.org provide powerful search interfaces powered by Xapian:
> +
> +1. **Direct message retrieval (MOST RELIABLE METHODS):**
> +   - Base URL: https://lore.kernel.org/all/
> +   - Message URL: https://lore.kernel.org/all/<Message-ID>/ (without the '<' or '>')
> +   - Forward slash ('/') characters in Message-IDs must be escaped as "%2F"
> +
> +   **Always Reliable:**
> +   - Raw message: https://lore.kernel.org/all/<Message-ID>/raw
> +   - Thread mbox: https://lore.kernel.org/all/<Message-ID>/t.mbox.gz (BEST for complete data)
> +   - Thread view: https://lore.kernel.org/all/<Message-ID>/T/ (NO fragments!)
> +
> +   **Less Reliable:**
> +   - Thread Atom feed: https://lore.kernel.org/all/<Message-ID>/t.atom
> +   - Nested thread view: https://lore.kernel.org/all/<Message-ID>/t/
> +
> +2. **Search query syntax:**
> +   Supports AND, OR, NOT, '+', '-' queries. Search URL format:
> +   https://lore.kernel.org/all/?q=<search-query>
> +
> +   **Available search prefixes:**
> +   - s:        match within Subject (e.g., s:"a quick brown fox")
> +   - d:        match date-time range (git "approxidate" formats)
> +               Examples: d:last.week.., d:..2.days.ago, d:20240101..20240131
> +   - b:        match within message body, including text attachments
> +   - nq:       match non-quoted text within message body
> +   - q:        match quoted text within message body
> +   - n:        match filename of attachment(s)
> +   - t:        match within the To header
> +   - c:        match within the Cc header
> +   - f:        match within the From header
> +   - a:        match within the To, Cc, and From headers
> +   - tc:       match within the To and Cc headers
> +   - l:        match contents of the List-Id header
> +   - bs:       match within the Subject and body
> +   - rt:       match received time (like 'd:' if sender's clock was correct)
> +
> +   **Diff-specific prefixes (for patches):**
> +   - dfn:      match filename from diff
> +   - dfa:      match diff removed (-) lines
> +   - dfb:      match diff added (+) lines
> +   - dfhh:     match diff hunk header context (usually function name)
> +   - dfctx:    match diff context lines
> +   - dfpre:    match pre-image git blob ID
> +   - dfpost:   match post-image git blob ID
> +   - dfblob:   match either pre or post-image git blob ID
> +   - patchid:  match `git patch-id --stable' output
> +
> +   **Special headers:**
> +   - changeid:    the X-Change-ID mail header (e.g., changeid:stable)
> +   - forpatchid:  the X-For-Patch-ID mail header (e.g., forpatchid:stable)
> +
> +   **Query examples:**
> +   - Find patches by author: ?q=f:"John Doe"
> +   - Find patches in date range: ?q=d:2024-01-01..2024-01-31
> +   - Find patches touching file: ?q=dfn:drivers/net/ethernet
> +   - Find patches with subject containing "fix": ?q=s:fix
> +   - Combine conditions: ?q=f:"author@example.com"+s:"net"+d:last.month..
> +   - Find bug fixes: ?q=s:fix+OR+s:bug+OR+s:regression
> +   - Find patches with specific function: ?q=dfhh:my_function_name
> +
> +3. **Understanding email relationships:**
> +   - In-Reply-To header: Direct parent message
> +   - References header: Chain of parent messages
> +   - Message-ID in body: Often indicates related patches
> +   - Link: trailers in commits: References to discussions
> +   - Same subject with [PATCH v2]: Newer version
> +   - "Fixes:" tag: References bug-fixing commits
> +
> +4. **Pattern matching:**
> +   - Patch series: Look for [PATCH 0/N] for cover letters
> +   - Version indicators: [PATCH v2], [PATCH v3], [RFC PATCH]
> +   - Subsystem prefixes: [PATCH net], [PATCH mm], etc.
> +   - Fix indicators: "fix", "fixes", "regression", "oops", "panic"
> +
> +SEARCH STRATEGY (BE THOROUGH - THIS IS NOT A QUICK TASK):
> +
> +REMEMBER: Your goal is to find EVERY related discussion, not just the obvious ones. Spend time on each search strategy. Try multiple variations of queries. Don't give up after the first attempt.
> +
> +1. **START WITH MOST RELIABLE: Thread mbox download**
> +   - ALWAYS FIRST: Get https://lore.kernel.org/all/{{msgid}}/t.mbox.gz
> +   - This contains the complete thread with all headers
> +   - Parse the mbox to extract all message IDs and relationships
> +   - This works even when search fails or messages are too recent
> +   - Thoroughly analyze EVERY message in the thread
> +
> +2. **Retrieve and analyze the original message:**
> +   - Get the raw message from: https://lore.kernel.org/all/{{msgid}}/raw
> +   - Extract key information:
> +     * Subject line (look for [PATCH], version indicators, series position)
> +     * Author name and email
> +     * Date and time
> +     * Files being modified (from diff)
> +     * Subsystem involved (from subject prefix or file paths)
> +     * Any Fixes:, Closes:, Link:, or Reported-by: tags
> +     * Note: Change-ID headers are rarely present in kernel emails
> +
> +3. **Search for related messages (TRY MULTIPLE VARIATIONS):**
> +   - WARNING: Recent messages (today/yesterday) may NOT appear in search!
> +   - Keep queries simple: ?q=f:author@example.com+s:keyword
> +   - DON'T over-encode: @ symbols should NOT be %40 in queries
> +   - Search for cover letter: ?q=s:"[PATCH 0/"+f:author-email
> +   - Find all patches in series: ?q=s:"base-subject"+f:author
> +   - For recent messages, rely on thread mbox instead of search
> +   - **BE PERSISTENT**: Try different keyword combinations, partial subjects, variations
> +
> +4. **Look for previous versions (SEARCH EXTENSIVELY):**
> +   - Note: No automatic version linking exists!
> +   - Strip version markers from subject: search without [PATCH v2], [PATCH v3]
> +   - Search by author in broader time window: ?q=f:author
> +   - Look for similar subjects: ?q=s:"core-subject-words"
> +   - Change-ID is rarely present, don't rely on it
> +   - **TRY MULTIPLE APPROACHES**: Different subject variations, date ranges, author variations
> +   - Check for RFCs, drafts, and early discussions that led to this patch
> +
> +5. **Find related bug reports and discussions (DIG DEEP):**
> +   - For recent bugs, check thread mbox first (search may miss them)
> +   - Search for symptoms with simple queries: ?q=b:error+b:message
> +   - Syzkaller reports: ?q=f:syzbot (but check date - may be delayed)
> +   - Regression reports: ?q=s:regression+s:subsystem
> +   - Use dfn: prefix for file searches: ?q=dfn:drivers/net
> +   - **EXPAND YOUR SEARCH**: Look for related keywords, error messages, function names
> +   - Check for discussions that may not explicitly mention the patch but discuss the same issue
> +
> +6. **Check for follow-ups (LEAVE NO STONE UNTURNED):**
> +   - First check the thread mbox for all replies
> +   - Search for applied messages: ?q=s:applied+s:"patch-title"
> +   - Look for test results: ?q=s:"Tested-by"
> +   - Check for reverts: ?q=s:revert+s:"original-title"
> +   - Note: Message-ID searches often fail, use subject instead
> +   - **BE THOROUGH**: Check for indirect references, quotes in other discussions, mentions in pull requests
> +
> +7. **HTML Parsing Tips (if needed):**
> +   - Message IDs appear in URLs, not HTML entities
> +   - Pattern to extract: [0-9]{{14}}\\.[0-9]+-[0-9]+-[^@]+@[^/\"]+
> +   - Don't look for &lt; &gt; encoded brackets
> +   - Thread view HTML is less reliable than mbox
> +
> +FAILURE RECOVERY STRATEGIES:
> +- If search returns empty: Try thread mbox or wait for indexing
> +- If URL returns 404: Remove fragments, check encoding
> +- If can't find versions: Search by author and date range
> +- If WebFetch fails: Try simpler URL without parameters
> +- If HTML parsing fails: Use mbox format instead
> +
> +OUTPUT FORMAT:
> +
> +Return a JSON array of related message IDs with their relationship type and reason:
> +
> +```json
> +[
> +  {{
> +    "msgid": "example@message.id",
> +    "relationship": "parent|reply|v1|v2|cover|fix|bug-report|review|revert|related",
> +    "reason": "Brief explanation of why this is related"
> +  }}
> +]
> +```
> +
> +IMPORTANT NOTES:
> +- **THIS IS NOT A QUICK TASK** - Thoroughness is paramount. Spend the time needed.
> +- **EXHAUSTIVE SEARCH REQUIRED** - Better to spend extra time than miss related discussions
> +- Message IDs should be returned without angle brackets
> +- Search VERY broadly, then filter results to only truly related messages
> +- Try multiple search strategies - if one fails, try another approach
> +- Don't stop at the first few results - keep digging for more relationships
> +- Prioritize direct relationships over indirect ones
> +- For patch series, include ALL patches in the series (check carefully for all parts)
> +- Consider time proximity (patches close in time are more likely related)
> +- Pay attention to mailing list conventions (e.g., "Re:" for replies, "[PATCH v2]" for new versions)
> +- **DOUBLE-CHECK YOUR WORK** - Review your findings to ensure nothing was missed
> +
> +UNDERSTANDING KERNEL WORKFLOW PATTERNS:
> +- Patch series usually have a cover letter [PATCH 0/N] explaining the series
> +- Reviews often quote parts of the original patch with ">" prefix
> +- Maintainers send "applied" messages when patches are accepted
> +- Bug reports often include stack traces, kernel versions, and reproduction steps
> +- Syzkaller/syzbot reports have specific formats with "syzbot+hash@" addresses
> +- Fixes typically reference commits with "Fixes: <12-char-sha1> ("subject")"
> +- Stable backports are marked with "Cc: stable@vger.kernel.org"
> +
> +KEY TAKEAWAYS FOR RELIABLE OPERATION:
> +1. **ALWAYS start with thread mbox** - it's the most reliable data source
> +2. **NEVER trust search for recent messages** - use direct URLs instead
> +3. **KEEP search queries simple** - complex encoding breaks searches
> +4. **AVOID URL fragments (#anchors)** - they cause 404 errors
> +5. **DON'T rely on Change-IDs** - they're rarely present
> +6. **PREFER subject searches over message-ID searches** - more reliable
> +7. **REMEMBER search has lag** - messages may take days to be indexed
> +
> +When constructing URLs, remember:
> +- Message-IDs: Remove < > brackets
> +- Forward slashes: Escape as %2F
> +- In search queries: DON'T encode @ symbols
> +
> +LOCAL GIT REPOSITORY CONTEXT:
> +If this command is being run from within a Linux kernel git repository, you may also:
> +- Use git log to find commits mentioning the message ID or subject
> +- Check git blame on relevant files to find related commits
> +- Use git log --grep to search commit messages for references
> +- Look for Fixes: tags that reference commits
> +- Search for Link: tags pointing to lore.kernel.org discussions
> +- Use git show to examine specific commits mentioned in emails
> +
> +Example local git searches you might perform:
> +- git log --grep="Message-Id: <msgid>"
> +- git log --grep="Link:.*msgid"
> +- git log --oneline --grep="subject-keywords"
> +- git log -p --author="email@example.com" --since="1 month ago"
> +- git blame path/to/file.c | grep "function_name"
> +- git log --format="%H %s" -- path/to/file.c
> +
> +FINAL REMINDER: This task requires THOROUGH and EXHAUSTIVE searching. Do not rush. Take the time to:
> +1. Try multiple search strategies
> +2. Look for indirect relationships
> +3. Check different time periods
> +4. Use various keyword combinations
> +5. Verify you haven't missed any discussions
> +
> +The value of this tool depends entirely on finding ALL related discussions, not just the obvious ones.
> +
> +Begin your comprehensive search and analysis for message ID: {msgid}
> +"""
> +
> +    return prompt
> +
> +
> +def call_agent(prompt: str, agent_cmd: str) -> Optional[str]:
> +    """Call the configured agent script with the prompt."""
> +
> +    # Expand user paths
> +    agent_cmd = os.path.expanduser(agent_cmd)
> +
> +    if not os.path.exists(agent_cmd):
> +        logger.error('Agent command not found: %s', agent_cmd)
> +        return None
> +
> +    if not os.access(agent_cmd, os.X_OK):
> +        logger.error('Agent command is not executable: %s', agent_cmd)
> +        return None
> +
> +    try:
> +        # Write prompt to a temporary file to avoid shell escaping issues
> +        with tempfile.NamedTemporaryFile(mode='w', suffix='.txt', delete=False) as tmp:
> +            tmp.write(prompt)
> +            tmp_path = tmp.name
> +
> +        # Call the agent script with the prompt file as argument
> +        logger.info('Calling agent: %s %s', agent_cmd, tmp_path)
> +        result = subprocess.run(
> +            [agent_cmd, tmp_path],
> +            capture_output=True,
> +            text=True
> +        )
> +
> +        if result.returncode != 0:
> +            logger.error('Agent returned error code %d', result.returncode)
> +            if result.stderr:
> +                logger.error('Agent stderr: %s', result.stderr)
> +            return None
> +
> +        return result.stdout
> +
> +    except subprocess.TimeoutExpired:
> +        logger.error('Agent command timed out after 5 minutes')
> +        return None
> +    except Exception as e:
> +        logger.error('Error calling agent: %s', e)
> +        return None
> +    finally:
> +        # Clean up temp file
> +        if 'tmp_path' in locals():
> +            try:
> +                os.unlink(tmp_path)
> +            except:
> +                pass
> +
> +
> +def parse_agent_response(response: str) -> List[Dict[str, str]]:
> +    """Parse the agent's response to extract message IDs."""
> +
> +    related = []
> +
> +    try:
> +        # Try to find JSON in the response
> +        # Agent might return additional text, so we look for JSON array
> +        import re
> +        json_match = re.search(r'\[.*?\]', response, re.DOTALL)
> +        if json_match:
> +            json_str = json_match.group(0)
> +            data = json.loads(json_str)
> +
> +            if isinstance(data, list):
> +                for item in data:
> +                    if isinstance(item, dict) and 'msgid' in item:
> +                        related.append({
> +                            'msgid': item.get('msgid', ''),
> +                            'relationship': item.get('relationship', 'related'),
> +                            'reason': item.get('reason', 'No reason provided')
> +                        })
> +        else:
> +            # Fallback: try to extract message IDs from plain text
> +            # Look for patterns that look like message IDs
> +            msgid_pattern = re.compile(r'[a-zA-Z0-9][a-zA-Z0-9\.\-_]+@[a-zA-Z0-9][a-zA-Z0-9\.\-]+\.[a-zA-Z]+')
> +            for match in msgid_pattern.finditer(response):
> +                msgid = match.group(0)
> +                if msgid != '':  # Don't include the original
> +                    related.append({
> +                        'msgid': msgid,
> +                        'relationship': 'related',
> +                        'reason': 'Found in agent response'
> +                    })
> +
> +    except json.JSONDecodeError as e:
> +        logger.warning('Could not parse JSON from agent response: %s', e)
> +    except Exception as e:
> +        logger.error('Error parsing agent response: %s', e)
> +
> +    return related
> +
> +
> +def get_message_info(msgid: str) -> Optional[Dict[str, Any]]:
> +    """Retrieve basic information about a message."""
> +
> +    msgs = b4.get_pi_thread_by_msgid(msgid, onlymsgids={msgid}, with_thread=False)
> +    if not msgs:
> +        return None
> +
> +    msg = msgs[0]
> +
> +    return {
> +        'subject': msg.get('Subject', 'No subject'),
> +        'from': msg.get('From', 'Unknown'),
> +        'date': msg.get('Date', 'Unknown'),
> +        'msgid': msgid
> +    }
> +
> +
> +def download_and_combine_threads(msgid: str, related_messages: List[Dict[str, str]],
> +                                 output_file: str, nocache: bool = False) -> int:
> +    """Download thread mboxes for all related messages and combine into one mbox file."""
> +
> +    message_ids = [msgid]  # Start with original message
> +
> +    # Add all related message IDs
> +    for item in related_messages:
> +        if 'msgid' in item:
> +            message_ids.append(item['msgid'])
> +
> +    # Collect all messages from all threads
> +    seen_msgids = set()
> +    all_messages = []
> +
> +    # Download thread for each message
> +    # But be smart about what we include - don't mix unrelated series
> +    for msg_id in message_ids:
> +        logger.info('Fetching thread for %s', msg_id)
> +
> +        # For better control, fetch just the specific thread, not everything
> +        # Use onlymsgids to limit scope when possible
> +        msgs = b4.get_pi_thread_by_msgid(msg_id, nocache=nocache)
> +
> +        if msgs:
> +            # Try to detect thread boundaries and avoid mixing unrelated series
> +            thread_messages = []
> +            base_subject = None
> +
> +            for msg in msgs:
> +                msg_msgid = b4.LoreMessage.get_clean_msgid(msg)
> +
> +                # Skip if we've already seen this message
> +                if msg_msgid in seen_msgids:
> +                    continue
> +
> +                # Get the subject to check if it's part of the same series
> +                subject = msg.get('Subject', '')
> +
> +                # Extract base subject (remove Re:, [PATCH], version numbers, etc)
> +                import re
> +                base = re.sub(r'^(Re:\s*)*(\[.*?\]\s*)*', '', subject).strip()
> +
> +                # Set the base subject from the first message
> +                if base_subject is None and base:
> +                    base_subject = base
> +
> +                # Add the message
> +                if msg_msgid:
> +                    seen_msgids.add(msg_msgid)
> +                    thread_messages.append(msg)
> +
> +            all_messages.extend(thread_messages)
> +        else:
> +            logger.warning('Could not fetch thread for %s', msg_id)
> +
> +    # Sort messages by date to maintain chronological order
> +    all_messages.sort(key=lambda m: email.utils.parsedate_to_datetime(m.get('Date', 'Thu, 1 Jan 1970 00:00:00 +0000')))
> +
> +    # Write all messages to output mbox file using b4's proper mbox functions
> +    logger.info('Writing %d messages to %s', len(all_messages), output_file)
> +
> +    total_messages = len(all_messages)
> +
> +    if total_messages > 0:
> +        # Use b4's save_mboxrd_mbox function which properly handles mbox format
> +        with open(output_file, 'wb') as outf:
> +            b4.save_mboxrd_mbox(all_messages, outf)
> +
> +    logger.info('Combined mbox contains %d unique messages', total_messages)
> +    return total_messages
> +
> +
> +def main(cmdargs: argparse.Namespace) -> None:
> +    """Main entry point for b4 dig command."""
> +
> +    # Get the message ID
> +    msgid = b4.get_msgid(cmdargs)
> +    if not msgid:
> +        logger.critical('Please provide a message-id')
> +        sys.exit(1)
> +
> +    # Clean up message ID
> +    if msgid.startswith('<'):
> +        msgid = msgid[1:]
> +    if msgid.endswith('>'):
> +        msgid = msgid[:-1]
> +
> +    logger.info('Analyzing message: %s', msgid)
> +
> +    # Get the agent command from config
> +    config = b4.get_main_config()
> +    agent_cmd = None
> +
> +    # Check command-line config override
> +    if hasattr(cmdargs, 'config') and cmdargs.config:
> +        if 'AGENT' in cmdargs.config:
> +            agent_cmd = cmdargs.config['AGENT']
> +
> +    # Fall back to main config
> +    if not agent_cmd:
> +        agent_cmd = config.get('dig-agent', config.get('agent', None))
> +
> +    if not agent_cmd:
> +        logger.critical('No AI agent configured. Set dig-agent in config or use -c AGENT=/path/to/agent.sh')
> +        logger.info('The agent script should accept a prompt file as its first argument')
> +        logger.info('and return a JSON array of related message IDs to stdout')
> +        sys.exit(1)
> +
> +    # Get info about the original message
> +    logger.info('Fetching original message...')
> +    msg_info = get_message_info(msgid)
> +    if msg_info:
> +        logger.info('Subject: %s', msg_info['subject'])
> +        logger.info('From: %s', msg_info['from'])
> +    else:
> +        logger.warning('Could not retrieve original message info')
> +
> +    # Construct the prompt
> +    logger.info('Constructing agent prompt...')
> +    prompt = construct_agent_prompt(msgid)
> +
> +    # Call the agent
> +    logger.info('Calling AI agent: %s', agent_cmd)
> +    response = call_agent(prompt, agent_cmd)
> +
> +    if not response:
> +        logger.critical('No response from agent')
> +        sys.exit(1)
> +
> +    # Parse the response
> +    logger.info('Parsing agent response...')
> +    related = parse_agent_response(response)
> +
> +    if not related:
> +        logger.info('No related messages found')
> +        sys.exit(0)
> +
> +    # Display simplified results
> +    logger.info('Found %d related messages:', len(related))
> +    print()
> +    print('Related Messages Summary:')
> +    print('-' * 60)
> +
> +    for item in related:
> +        relationship = item.get('relationship', 'related')
> +        reason = item.get('reason', '')
> +
> +        print(f'[{relationship.upper()}] {reason}')
> +
> +    print('-' * 60)
> +    print()
> +
> +    # Generate output mbox filename
> +    if hasattr(cmdargs, 'output') and cmdargs.output:
> +        mbox_file = cmdargs.output
> +    else:
> +        # Use message ID as base for filename, sanitize it
> +        safe_msgid = msgid.replace('/', '_').replace('@', '_at_').replace('<', '').replace('>', '')
> +        mbox_file = f'{safe_msgid}-related.mbox'
> +
> +    # Download and combine all threads into one mbox
> +    logger.info('Downloading and combining all related threads...')
> +    nocache = hasattr(cmdargs, 'nocache') and cmdargs.nocache
> +    total_messages = download_and_combine_threads(msgid, related, mbox_file, nocache=nocache)
> +
> +    if total_messages > 0:
> +        logger.info('Success: Combined mbox saved to %s (%d messages)', mbox_file, total_messages)
> +        print(f'✓ Combined mbox file: {mbox_file}')
> +        print(f'  Total messages: {total_messages}')
> +        print(f'  Related threads: {len(related) + 1}')  # +1 for original
> +    else:
> +        logger.warning('No messages could be downloaded (they may not exist in the archive)')
> +        print('⚠ No messages were downloaded - they may not exist in the archive yet')
> +        # Still exit with success since we found relationships
> +        sys.exit(0)

-- 
Regards,

Laurent Pinchart

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16])
	(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 9E0A131CA7D;
	Tue,  9 Sep 2025 17:25:17 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=198.175.65.16
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757438719; cv=fail; b=snvP2X8eFdhtumeq6fMFsoamK5uvjhlf8AvV+oPiGKnA2Bqcxwkl4WXRDi62ygChe/BuuVScBMXZSKc6BtIMHnSbiXFoX1l8d+oh0Jwy5bUNXQA/TwqgygxsRnpShNMDF4eMbmfy/2x9pk8+sOMe5O4fVV/6dK9pX8qOUOlFRDE=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757438719; c=relaxed/simple;
	bh=EWvnKiEokZpAHSJxGJUluuHjkTrS8nuOhCkQlgIuUKc=;
	h=From:Date:To:CC:Message-ID:In-Reply-To:References:Subject:
	 Content-Type:MIME-Version; b=uu+GeJL7JX3OirfVKHQqG84hHKWf4Z8QgJYaamQrdZmv+Jdg6ZwVE0wmwZR3giuE8A0t8fqk54LTXtrSGEI0MDCRPdLhPFJ5vioiZexedsqUzsMi9pT4klM3D9Bg8FBh9bSi0e//D/KkPj6al/UBQwdSTUPlaUffK66+R2HAiFY=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Wxq/P2um; arc=fail smtp.client-ip=198.175.65.16
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Wxq/P2um"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1757438718; x=1788974718;
  h=from:date:to:cc:message-id:in-reply-to:references:
   subject:content-transfer-encoding:mime-version;
  bh=EWvnKiEokZpAHSJxGJUluuHjkTrS8nuOhCkQlgIuUKc=;
  b=Wxq/P2umv8Gg6KmjLkcIAPxZYlzPe/WgQvUSoa2+xyaGb10okQ0M7s71
   7j4JKn9kPAh6yjmJfsSRFztaDBZ1fRHzMRMvBPrEnU4BKL5pvTdwNNUA4
   BCO8DKX2uVGYKIzCIgSKcxfkzq/6kFpG1ZvnYYIvj1urc8lPgXObtJC29
   3qhT2zgaMKWVozSPh2D+cBz0SSQyDqLxGK1UDYEyLg+wjYbJFq40ESXmS
   bSg12wIzf/yzick38c1ngUOx++A8o2BN6C71sA8ZLGwBqmrHFk9AyjPii
   vrhPTVajXXYPROAPcF8s91I2uTt8eQOfkT5XZR2vXOC4VNfV1/yW3KGn1
   g==;
X-CSE-ConnectionGUID: UVLOs2qvRhi9doqJl4bGTg==
X-CSE-MsgGUID: GthTlkfMSqmrrpHDLPi4oA==
X-IronPort-AV: E=McAfee;i="6800,10657,11548"; a="59878414"
X-IronPort-AV: E=Sophos;i="6.18,251,1751266800"; 
   d="scan'208";a="59878414"
Received: from fmviesa006.fm.intel.com ([10.60.135.146])
  by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2025 10:25:17 -0700
X-CSE-ConnectionGUID: C9CT0QQ7QW2vsc9sClGphA==
X-CSE-MsgGUID: EaK9hYKvRom8//jZzOz9Ew==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.18,251,1751266800"; 
   d="scan'208";a="173058218"
Received: from fmsmsx903.amr.corp.intel.com ([10.18.126.92])
  by fmviesa006.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2025 10:25:17 -0700
Received: from FMSMSX901.amr.corp.intel.com (10.18.126.90) by
 fmsmsx903.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Tue, 9 Sep 2025 10:25:16 -0700
Received: from fmsedg903.ED.cps.intel.com (10.1.192.145) by
 FMSMSX901.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17 via Frontend Transport; Tue, 9 Sep 2025 10:25:16 -0700
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (40.107.220.59)
 by edgegateway.intel.com (192.55.55.83) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Tue, 9 Sep 2025 10:25:16 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lCBqorQhi7z2Rm2G0cS3/NFebFwKQm6EFdo2fNtyBF+BP0+bivgt0NmlLcLkxyYutvkgbsKWf2Kh31eR5JJOqVEEudO5qYciPhU5aE2gPsDMlQ/okxVSsPSKAdBrOWKMnYwNdLvYR5SXxcbAEN8H59QyvA04pal19s7cAWfU7o44Lwc1h41f+DTgdGg8OVp4TG6FGbrQASgkKM7IzHEsBgwlw6VcIJWvWo+tnMCitLHiKrmNABDeLKPdSaBF+qSsEIrY96sTHHyCjiKHUalNfKhEeotUDPHbIcruce4u+FtNUqgm5rovn6Pil0V9BxXYXt65QM3qmh37Ywii3VfDCA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=50GxkO/potxKWgInj5Uib89bTunez6X0qXr3vp1sTQE=;
 b=djNnteKYukAGgJhhr/sZ2orNb4ZDmyzw3gFEH5CW2nikjzg7UbnHbOYARLceFrZrsYMAuUHpcteuv/WyUdJCqXKPB570Q1y7mPE4JkHv9DFww3tTkmhXuebGoCITB5a5ScMazeu2FB4Jm15qiuO2BjUSYEdwwjAsQTwdTEkfKzLnnZc5SxQfeW/Mb6JhbL4emXGg7ETKnrEwCyjbYmuLqJBGCA1zTrwHDJbk0adfAEZT0tGf+kt56uRUinLjhz6ZDGlxbVCaWSDOtUpSTG5dAcIsQnMHEgAiNA79NWFMssOZgR6kxtBYk3510sWn3gsmFo/DnX5zFwITqDak96LBAA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;
 dkim=pass header.d=intel.com; arc=none
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=intel.com;
Received: from PH8PR11MB8107.namprd11.prod.outlook.com (2603:10b6:510:256::6)
 by CY8PR11MB6889.namprd11.prod.outlook.com (2603:10b6:930:5e::9) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Tue, 9 Sep
 2025 17:25:13 +0000
Received: from PH8PR11MB8107.namprd11.prod.outlook.com
 ([fe80::6b05:74cf:a304:ecd8]) by PH8PR11MB8107.namprd11.prod.outlook.com
 ([fe80::6b05:74cf:a304:ecd8%2]) with mapi id 15.20.9094.021; Tue, 9 Sep 2025
 17:25:13 +0000
From: <dan.j.williams@intel.com>
Date: Tue, 9 Sep 2025 10:25:11 -0700
To: Linus Torvalds <torvalds@linux-foundation.org>, Jens Axboe
	<axboe@kernel.dk>
CC: Vlastimil Babka <vbabka@suse.cz>, Konstantin Ryabitsev
	<konstantin@linuxfoundation.org>, Jakub Kicinski <kuba@kernel.org>, "Rafael
 J. Wysocki" <rafael@kernel.org>, <dan.j.williams@intel.com>, "Caleb Sander
 Mateos" <csander@purestorage.com>, io-uring <io-uring@vger.kernel.org>,
	<workflows@vger.kernel.org>
Message-ID: <68c062f7725c7_75db100eb@dwillia2-mobl4.notmuch>
In-Reply-To: <CAHk-=whP2zoFm+-EmgQ69-00cxM5jgoEGWyAYVQ8bQYFbb2j=Q@mail.gmail.com>
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <68bf3854f101b_4224d100d7@dwillia2-mobl4.notmuch>
 <5922560.DvuYhMxLoT@rafael.j.wysocki>
 <20250909071818.15507ee6@kernel.org>
 <92dc8570-84a2-4015-9c7a-6e7da784869a@kernel.dk>
 <20250909-green-oriole-of-speed-85cd6d@lemur>
 <497c9c10-3309-49b9-8d4f-ff0bc34df4e5@suse.cz>
 <be98399d-3886-496e-9cf4-5ec909124418@kernel.dk>
 <CAHk-=whP2zoFm+-EmgQ69-00cxM5jgoEGWyAYVQ8bQYFbb2j=Q@mail.gmail.com>
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: SJ0PR05CA0205.namprd05.prod.outlook.com
 (2603:10b6:a03:330::30) To PH8PR11MB8107.namprd11.prod.outlook.com
 (2603:10b6:510:256::6)
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR11MB8107:EE_|CY8PR11MB6889:EE_
X-MS-Office365-Filtering-Correlation-Id: a20e8b0c-7c50-4fc3-a339-08ddefc5d5d3
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014;
X-Microsoft-Antispam-Message-Info: =?utf-8?B?M3NURGVtazJzcmxYOStNa1JmSjRRYjVPY3BpWDZHMjFJYXR2S2d1dEs2bUYx?=
 =?utf-8?B?b0ZBeTVHVEt0L2NjcEl3cm9NN2tXWDlIM1FoNWxUcTd4Z1dtUkNnMllZRWtv?=
 =?utf-8?B?MFBibU1QbUpvR3Evb0JPZm9SaVNTYnVhSkRGRlI3cXlkclV5Ti9lSkkyV2lH?=
 =?utf-8?B?N0ZHSnV1UU4vbFdTOGI1ckJIbzdIQW9nU2MzeFJ6YWhLQ0k4ZVJ2V2t3Yllj?=
 =?utf-8?B?UFJwd0xCVi9ESHMrcjZiNEFQek1RMmVpRVhncnRZUnBjYUVMelV3bU1CU0Zv?=
 =?utf-8?B?WkRhYURQQXRHSVlHWEozRUVHcjkvd1lhSk1hcWp1KyswVlZDZ2ZZVVVxbDF4?=
 =?utf-8?B?UzlOb0ticmN6cGcxUFdacmhEMWlGRENmdWVpSnpsOVJ1bHpXVHNtaUkweWtW?=
 =?utf-8?B?UExtTUpZcEZMZGpyVHNsb051WWRsN0RBMjJtcjFyUzd1WjlqcGI5NGVISksz?=
 =?utf-8?B?SkloYkFhdXVJd0ZUc2ExNjlTWjlDaDFCdi9CQzN1K21LczFyblkrbGMzNnNT?=
 =?utf-8?B?SVEyWG1jdElUUFM0encraVRiS2ttR2JNOXB5QVNMOVRoSTJEWDJrNFRNTGJT?=
 =?utf-8?B?QWxCSGZoT3dwUVoxUzhiMEc2VmpPTnJTeUdqTU9nYW1wQW1SMks2THIxYnVx?=
 =?utf-8?B?WDFxV0ZTb2JCN0xUVWFhL21ReHFTcHg4WUQvbzBrS0o2RGJPNm5BaWF6RU1j?=
 =?utf-8?B?RUlPV0E3aW1kODd0MXpjbmpLTEJ2RC9iVi80VEVPcGc1V0wxeWNLRFMvZk44?=
 =?utf-8?B?dHdhTFZXU1YwYlR5VlcxWXdUZXowenZiSG80akd4VW4rTjhBZ1FoUTdDWFpx?=
 =?utf-8?B?QStOc1ZoL2RZNXk5TmdCVzl0cmlTeUJjVlowL2JmNHJIZGdCRnhQbnowWlp1?=
 =?utf-8?B?S1k5ZHgwdVlOYzE3akEzWUd2ZUVCaGFMbi9hNUhWdEoyWGF6QVJFS1pwT2tB?=
 =?utf-8?B?UW5uMkNIeDhTenphbm10aEtlR2F0aGV4REFlQjdjU2kxVFluUHh4UGwyclZh?=
 =?utf-8?B?a09pakdZTk8yQWZDQ0dpOXVEbWVZY0FhL0ZYb2x2REZjZllZQmlwbU83cnVo?=
 =?utf-8?B?eFIrdmJ2Q3MxRXAyeHRSTjU3d2QxMUVkTnBrdlRzVWZHNkxoZFBMQUY0eTZn?=
 =?utf-8?B?Wk1iU2pqVVgySnp4akVmNzRNTzI0WExNWjV4djhtOFRuNlhaYmpCcnZQKzdz?=
 =?utf-8?B?TFNwdHp3MTB2dEp5ZDBSemdLZDRCR2pGWkZZWGJNVjFHcUo3NDJiWTlYWThu?=
 =?utf-8?B?K09xenBKUHpKNDBuNWdPcnQzemY5L052MlhJT2xmUm9pbzh0OHdvbDNmQ3Fq?=
 =?utf-8?B?bFpQcEZnOFVTTkJ1cU45ZkJ6WlNlNk1PNzhmU3BVNE5WT1ZkMjNjTzBJRVZG?=
 =?utf-8?B?bjZMV1h3V2ZpdmU4dnN2RnFkdExYYi9TcnlzeGJjcFRhQWdLNUpndFFiNm1j?=
 =?utf-8?B?SDBQK3VKQjFPYnFiNTk3eThJdXVVdUNGN21jc0NXV3RsVVRiMlRLTUdibDI3?=
 =?utf-8?B?TXZvVUdmS1lEbzFYUkVTU3UyMUJsQXF1cGF4bGNpVVY1azc3ajRaTzQ2UE9Z?=
 =?utf-8?B?MWREakxoYm5kUG5kOEFWN2lvampaWXdwMDNoeWk2dkxGOTBRMzlya1BSN1dM?=
 =?utf-8?B?OCt4OFNWZWwybmhOWExmY1dqK2E2bzZXL1V5R0Z5eEdRcWNVTi9LRy81aTJU?=
 =?utf-8?B?RTU3VFlYZU5ETmJFSW5rOE1pbFRQZk52OFhnRzFpMWRmOW8yWlhMdHUweFNR?=
 =?utf-8?B?ZlhDQnNsd0R2U0txOGVVdTIvYmxlUEtrYkpEeng2eEdSdE5QZHZmbW5tRkkz?=
 =?utf-8?B?Vm5tN0FYRmwvYlo0WERseHdXTWpzMjV2UEFmOTIveFRwK2t3TGxFUkE4elVO?=
 =?utf-8?Q?yE3oiYCMr4LPD?=
X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH8PR11MB8107.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eEVzeW9NUEtZSUNDRmUzWlJRaFRURmRYMzQwbVlvWGlvYXBBcFhPcHFMTHRH?=
 =?utf-8?B?YVF3RVFJdjlSdE9RekdzOVE0ZVAyc2wxcVUrNzkzbkhrT2hEUS9QT2wrV3BB?=
 =?utf-8?B?VDNzNmwxWWhVVUlnWXQzeTFVRVNCWEdUdE8yaXRhY0RTRW5DajlwcHJWQ0RU?=
 =?utf-8?B?aUxiT2RSVk9vRFU3bWx3bjFsSWhJYVNRN3Y1Y1BaMWRlZFlOMjd2MS9VZ2Fh?=
 =?utf-8?B?K2E5dldVR0NIbWpSN0c5WnJBZUY5azdIdk9qV3ZLanJmVm1vdlBuSUE2QjNP?=
 =?utf-8?B?MHhsOGxGYWZDcmhsUzJJK1pKYlowY21Gb3ZTaXdDbnhOTDc3S1N5VDNqQWhN?=
 =?utf-8?B?RE5BV2l5a3ZRTzFYcTZRVEhoYnZaTk9mZjAwSkFXWmRmYkp2dGNib2xFSFBH?=
 =?utf-8?B?bkI2V1RlcDgvRTk3UWJlSnRjK01TRVk1Q1Vua3BiSmVDS0l5QnFSWHVWZnNp?=
 =?utf-8?B?OFdhcW1OeTd0dllQTWFYTFpRa2xjN0xBdHF1SExxRk5oazdZeDhTNjNXd1R6?=
 =?utf-8?B?STBvMVRESXAwT0o1bEdtbXE5bm1TUk9pUFV2a2JRbnRReG44eWxUWEJueGZR?=
 =?utf-8?B?bWJ1ZHVhZkJ4UFFMWHJOM0NjZUlYa3E4VzNIY2ZoWHF4dDJvQ1VMQmtRLzUz?=
 =?utf-8?B?OEJ0M3lCb2hPZDlnMkQwNnlZVUY2ODloRGFlVlpjdmQwUUJnMlYwMFltc1c5?=
 =?utf-8?B?bWFkbWM3Yzd3aVloYk9FNklFRUh5SWNJdXFjRW1CNzBrWnRQdDFoTHNYNlA1?=
 =?utf-8?B?enpXUUdwcDUraUNyY0pPUzNqNlEvcy85bElBTGJWNWc1bE1OT3hXdFYybUtz?=
 =?utf-8?B?Z3dUYVlUd3IwQ2ZON1UvWWsxR1dGdHlHUmNnSmJwUmtGWGpYdUpWUVFydXlN?=
 =?utf-8?B?N3VsdzMxek15bXFBQTVPZGlMU0grbHRqNG1vR1o5b0h1K2g5RmhBa1FJbW1w?=
 =?utf-8?B?WkF3eHR1ekQvR3lDS0Mra2NNYm1EZm44TjMxRGFXVzBFa2duK2pkMGdPSjRj?=
 =?utf-8?B?TXc5YUZjazJjbFRqSFUyWTBDYmV4NjB5ZTBZSjBSczJvdVdUNE5sbTNNMTMz?=
 =?utf-8?B?UU9uUSsyV1pGN0dWZDRNZ2M3RFdZVnFBRW1XU0RXV3BER3p4Ymg4d0p6dlEz?=
 =?utf-8?B?U01ENzgyRnJrcnpJQXRUeG1wa002cGU4RE1lVDlGNlRiTXNlZXdCR01pZ3JW?=
 =?utf-8?B?NmdFWkZQN3Y5MVFZZ0xzbmdKQWs1M2xmTDlnckNJakp4WDIxVlZTcVhCNGlQ?=
 =?utf-8?B?Mnl3UEpDQmxVd21zYU5YUVJVajBzMlRweVpSYlRZajE4SnE1VFNPMzlKNFRD?=
 =?utf-8?B?K0FMZzkwRjdBMWtkYkJiOWdwSG56TkdXTUthV3Zvei9BdFdRUDZMTmVoNkdh?=
 =?utf-8?B?Z2poaFdtQ2hTQzhENmpvbVp5UHBnQXJnMXg5bDl2WGxPQUVmeml2c2FZMFBr?=
 =?utf-8?B?Z3cxZmVHY3U1Z29CQjllR2pYL2I0VVlnQ2F3bjZIUjlZRFVHTHdJQkQ3SzFD?=
 =?utf-8?B?L0wyWk9GclcrY2diN0tPZXJXNWJoaGRoempGRzlSQllmT0NLcTVtZVVzNWFx?=
 =?utf-8?B?TzcxSW85c2xUc0lnS3hUUm83Y284QmpoS3lzcHRFZ2tVeU5keEkvVC9DdHkz?=
 =?utf-8?B?L1libktPQXRwZHUxRWphVEpmSHcyYlVjUDlvQ1FLMUZGM3g2cXkxVHpscEcv?=
 =?utf-8?B?OG9kdWFJT21hRTFsUCt5WUorTnBoWXIrQW1zbEVBTW5kNnFjVUR4amFQa3FM?=
 =?utf-8?B?YXlna2xyRUdjL3dpbk5oRUFadzNMNTFCK0FEN0JKWnh3RHNPYmEzWUJ2a3hM?=
 =?utf-8?B?V3ExTXdZcWxDOVZnMHZaM1pLNVhWZ2JUQnREbERKSm5TNkx2aWlET2xiMWR2?=
 =?utf-8?B?aG1qUGxmY2VObjhieVJ5c0xUTnlnbnVlUlQwZ2wramE3V0M1Ym5ENXJXdEVI?=
 =?utf-8?B?aDY2MVZxZ0Y5aGl2NC9EeG9HOGRpWjE5Rm44andNeUJTeTRBNXVNangzUUZZ?=
 =?utf-8?B?c2k5YUVadFBQdVVnVnpGVVpkNlZDUHo0NFZ3cHBaaEU1eVlQMnBFcjJkNWpr?=
 =?utf-8?B?MnJTNFBrbGRycE5vRDZHYkpaVExPek42UG1UbmlYR0ZLZ0Uvd3ZMSnpxZkpN?=
 =?utf-8?B?R0w1bFEvN3VwUm55TE5zUit0V21mNjJpcHhZYWlXNVZ0L3dxZkIza2lndlRo?=
 =?utf-8?B?MHc9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: a20e8b0c-7c50-4fc3-a339-08ddefc5d5d3
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Sep 2025 17:25:13.3294
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: dwn4IxR+KZdMLBPWG+rdetWnYYFzpgRTDi+WlCickYm05GztNHIzJgFX/d0SnwyMa9Dl6JjejY4q50KcLL85kKmiGcj44mwHbY+Df53Q3zA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR11MB6889
X-OriginatorOrg: intel.com

Linus Torvalds wrote:
> On Tue, 9 Sept 2025 at 07:50, Jens Axboe <axboe@kernel.dk> wrote:
> >
> > I think we all know the answer to that one - it would've been EXACTLY
> > the same outcome. Not to put words in Linus' mouth, but it's not the
> > name of the tag that he finds repulsive, it's the very fact that a link
> > is there and it isn't useful _to him_.
> 
[..]
> Honestly people. Stop with the garbage already, and admit that your
> links were just worthless noise.
> 
> And if you have some workflow that used them, maybe we can really add
> scripting for those kinds of one-liners.
> 
> And maybe lore could even have particular indexing for the data you
> are interested in if that helps.
> 
> In my experience, Konstantin has been very responsive when people have
> asked for those kinds of things (both b4 and lore).

Hmm, good point. Lore does have patchid indexing. This needs some more
cleanup but could replace my usage of patch.msgid.link.

firefox http://lore.kernel.org/all/?q=patchid%3A$(awk '{ print $1 }' <<< $(git patch-id --stable <<< $(git show $commit)))

Now, it does drop one useful feature that you know apriori that the
maintainer did not commit a private version of a patch. However it
should work in most cases.

It would be nice if that was guaranteed to land on the latest version of
the patch just in case that patch was posted in several versions without
changing.

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2CFC13568F2
	for <io-uring@vger.kernel.org>; Tue,  9 Sep 2025 17:26:20 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.166.49
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757438783; cv=none; b=K3i+GIoN0lYCIUolGTbTQUfXpQRSwlE39xo8bqrFTeTeug+tDWqyCTcu/TrwtnVB6zmNHUYkt2ZQo8Fo95RDnbH8bm0xJhzKi2GizYWbpx2k1O5Kj6H0FdyxENirLCxjWyw1urp/grAauW2F4Yjqbe3lyT5K01/cjHrdkECnC8I=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757438783; c=relaxed/simple;
	bh=w3dda49bNz9voqj0u5TQ4cIEZEIRTG781SvVnQ2M8+E=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=BG0erHLAMxfoVAvOAsoDawEU/KG6qi3qBoku0XPwOfxVx924Trka/ab8tXFB5eIKk4kCBPBp0Zgd11B4vqYdrhEVUvDWK85N8HOUBF6Z5NdvFChJMGTlWs4d/Lotlb1fJs0QZC8Cy9jBkEQzG9z6el+BRzG5Dm+3BDi9nxoLE5k=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk; spf=pass smtp.mailfrom=kernel.dk; dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b=VcCaMTv2; arc=none smtp.client-ip=209.85.166.49
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kernel.dk
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b="VcCaMTv2"
Received: by mail-io1-f49.google.com with SMTP id ca18e2360f4ac-88758c2a133so536323239f.0
        for <io-uring@vger.kernel.org>; Tue, 09 Sep 2025 10:26:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=kernel-dk.20230601.gappssmtp.com; s=20230601; t=1757438780; x=1758043580; darn=vger.kernel.org;
        h=content-transfer-encoding:in-reply-to:content-language:from
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=ZXzL+MzBMX4xvnA/6SWkWrF76gCtEMsscBnEBOB1jMw=;
        b=VcCaMTv2suqC5faQX2pBWCioe1OYsCJ4bfms7giRM337sFhpVYpB90Fxny53UIp3Zq
         DitQITqzhwXJTsqXCDWftMfB0ZSv+lIBrjAxvmEkDwxWbb9Cy6Tb4zgOE0TRsLS5YHeD
         pVzipsU2Gf8chvAMBr1Z0uCe15ZxiSoAmUzqitePhdilGpHf3tu3nT44TrOgY3bfOXnG
         lUA7fU+DdZG+ch8j0ZJmZc3APLO8KsQvUhvPsyLzcRf9BjfdI19ih+r9HNtkCrWm8gqd
         DMRnKeKNjPrNEz22VtQu9tyPiwtLOG/JSOnzBBPj0Rg8YNaiOOixMjpvoLRuwDOcNWqh
         hwbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757438780; x=1758043580;
        h=content-transfer-encoding:in-reply-to:content-language:from
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=ZXzL+MzBMX4xvnA/6SWkWrF76gCtEMsscBnEBOB1jMw=;
        b=t2tZS6DQgE7acYIFM0ehiR8oY6Ys1Pe4g6sbrDuBA0kvWlg1sju3JrM22Qg0isqsKj
         bm6vsQA3Esiw9bxzaAuZEfwR3BZ1t63lJZnp9Q+qc4EC5Bb0GJmydb7rA6BnJAkFq9kN
         GNsGkaKhJqU4HpgdvFxJ6Y9ml0KD+DNMTNBlgnqV7fx/VzW3AdHfrioOWSioO1FhZx7t
         OqMCRoo+2DMqCvuu0+W11IE49/v02uk//O0dZQ2mbL0HUO/cYo5D0EaItsrtFYMC28oo
         zT9He/q184HJLSPqxNqFkEmjJdziXGDj+EljJK/F/7P7UXiHUBW/UqhyDW5He2Cn3wBF
         1qAA==
X-Forwarded-Encrypted: i=1; AJvYcCXxlvkQJ4bw4dwHDbPk/QVBGgkCsVWFqbhiXdT65s09MIl36o5SMoMjgtQmBKCLC02OZQbadrRIiA==@vger.kernel.org
X-Gm-Message-State: AOJu0YyUVgCMEwMh8C8POLf7FUZk1QWfKJNn3aZxnXsY2mDFrZHTXMVc
	KvCZHmun7YuNljSlScDC0Nc8tEzmzeJL7Opmp/5xmHq3aQhB18Aus+yMhBeM7wZ+ln8=
X-Gm-Gg: ASbGnct1dtlluMyvnedPu/IUx59MzLUAXCcewAulUa6q/GgpaaPxUggHHxeOs177cqu
	L9YDt0LwTye0Ozzlu2xAepYMPhuZhswbnhxyjU/XOMxNoLnjuQeYiRHHlKQ6usLAMRNiG/hiEVL
	uDQ3Bf+RwfwL9+mvZePEtxCvCZtnJlrRPCNZiMM7F6Ebq9f3Ysyp/CzHml1YlGRoowHqDcr6u/R
	jdfhukTqC5goyRVqo041KNP/Hb8nioNlOByhSs9liU5BMLiBez19/+/132/RBFHS8KK+jMX/D2X
	SIqwZ5jwv2o4sNnLGABLDXpEK3YT2hpejQjuQamn3o0bmzIIYj/t3aHxg2R/1yfond7p9sdCjEb
	gUaOQPhICnwtR1dedS+c=
X-Google-Smtp-Source: AGHT+IEDIJxRrCDoRd0PL3WQuDi8SnQ/UVNbt2HDmkns706+HN5Aesz/cR8Hq7g5UkgwMebu0TbTUA==
X-Received: by 2002:a05:6e02:12c3:b0:409:5da6:c72b with SMTP id e9e14a558f8ab-4095da6c7cfmr109467745ab.4.1757438780266;
        Tue, 09 Sep 2025 10:26:20 -0700 (PDT)
Received: from [192.168.1.116] ([96.43.243.2])
        by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-50d8f10a1e1sm9912093173.35.2025.09.09.10.26.19
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Tue, 09 Sep 2025 10:26:19 -0700 (PDT)
Message-ID: <72dd17ad-5467-49d3-9f40-054b1bf875d5@kernel.dk>
Date: Tue, 9 Sep 2025 11:26:19 -0600
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC] b4 dig: Add AI-powered email relationship discovery command
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
 Sasha Levin <sashal@kernel.org>
Cc: konstantin@linuxfoundation.org, csander@purestorage.com,
 io-uring@vger.kernel.org, torvalds@linux-foundation.org,
 workflows@vger.kernel.org
References: <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <20250909163214.3241191-1-sashal@kernel.org>
 <20250909172258.GH18349@pendragon.ideasonboard.com>
From: Jens Axboe <axboe@kernel.dk>
Content-Language: en-US
In-Reply-To: <20250909172258.GH18349@pendragon.ideasonboard.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 9/9/25 11:22 AM, Laurent Pinchart wrote:
> On Tue, Sep 09, 2025 at 12:32:14PM -0400, Sasha Levin wrote:
>> Add a new 'b4 dig' subcommand that uses AI agents to discover related
>> emails for a given message ID. This helps developers find all relevant
>> context around patches including previous versions, bug reports, reviews,
>> and related discussions.
> 
> That really sounds like "if all you have is a hammer, everything looks
> like a nail". The community has been working for multiple years to
> improve discovery of relationships between patches and commits, with
> great tools such are lore, lei and b4, and usage of commit IDs, patch
> IDs and message IDs to link everything together. Those provide exact
> results in a deterministic way, and consume a fraction of power of what
> this patch would do. It would be very sad if this would be the direction
> we decide to take.

Fully agree, this kind of lazy "oh just waste billions of cycles and
punt to some AI" bs is just kind of giving up on proper infrastructure
to support maintainers and developers.

-- 
Jens Axboe

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9E4E21C863B
	for <io-uring@vger.kernel.org>; Tue,  9 Sep 2025 17:50:42 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.49
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757440244; cv=none; b=NyMNxLDbosRTDNkD3xo2yDQLoh84MCZL14QFo5FOBDtlvk3eWUfkGRhW/f7BhzkaicRZhYhHUYB8HDpyugpguH3v17UOQc41y4Hbzrt57hNt9ulJgBOlQ3Gc1TdKOeZZjBibsByC3m1QoMT5IT212n2bQ2SinbJbXAtoy2+x7wk=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757440244; c=relaxed/simple;
	bh=PficCqT+rEbrs5pcKADEXtmjS2T6Jp/bREqqflB7AEk=;
	h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
	 To:Cc:Content-Type; b=mlZttI26UgKqupbil3EjCp7rbnk5IeGyGev8NJm4Brr2moAoIroD9AhaFPk8MortNioxmOrZecy46wp0tIcx2qMxUCggKb385zdeAyxTSQqni0VstKZIOzBGvOblJSPHLkJsiOGIHlm9tZVrgbRicQ08o+XlPkwGh4kY4QLexWY=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org; spf=pass smtp.mailfrom=linuxfoundation.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=fU2/lPRK; arc=none smtp.client-ip=209.85.218.49
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linuxfoundation.org
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="fU2/lPRK"
Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-b042cc39551so1060368666b.0
        for <io-uring@vger.kernel.org>; Tue, 09 Sep 2025 10:50:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linux-foundation.org; s=google; t=1757440240; x=1758045040; darn=vger.kernel.org;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=Q9ayI9RafIVeDOxPGUeZSrHU9WK0+PURxl43r1e78tQ=;
        b=fU2/lPRKy44x/fIuO5Skevrg7DK3uEg0N+CLuY168u5Kx2dDj6jPvd5BM0Is2FWziv
         W+rYQ+36LkFRWDeefm/AxYKLY4mS3P9r61B6Xjh6PXWXOslE9JEgxirS8NoqwEQ+EQKE
         AU9UfKIMiZT4fqRvIWL3V/ybjRRRZ79Oka16U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757440240; x=1758045040;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Q9ayI9RafIVeDOxPGUeZSrHU9WK0+PURxl43r1e78tQ=;
        b=k0GI//ooVVTFsGxy++2QjPH2VeqD8vgpf7U8MaahrImX1EqVpjoBhOtBIp2PHdC45v
         GAwZDzwsXbK3bi1FzFPDxm6smOjQbgcZR5iemdhV5u4bArHUpgZokcDb/HTVY8aPU1YU
         EN97xZk8GIoY6AHwCUTRaHVchJiISD1Wmu3ia5H1bGcM+MgoWqIrjEfYDGaRhNXUH+q/
         3QVwnzOVu+YDd6dRBWsSA8nPfqzJO8JkVx74JX2kxPmK2oE5f/ml5PY18L9k5N5xy80C
         1iDk3syzvZpcgW2/d3LR9/MCZB2erRPN76gNkuo3Y9eY6GVNd51lydqC7wPSjUphw77Q
         I65A==
X-Forwarded-Encrypted: i=1; AJvYcCVCUKdnu2aMHZ8XLRyabJm28sKzDnxkzrnkFy7a5FPZruzzIZd1R7tQif1zJpnGSET+0EIUsrIu5w==@vger.kernel.org
X-Gm-Message-State: AOJu0YwaMxD1LeEkryduyNauGtWg/5FX19l5foICWo8gxQkES6DzkHgi
	L/myuMcESfDypSKB33iI0il23nMsFbCjNFEpyhEgvQhbUQ9S+R4Qk4dV8UqsVSslvJYJrOjSysQ
	T7jyoJyY=
X-Gm-Gg: ASbGnctf0JwCxYgET1TIXx4Aw1DdVFwQWd6kc5FQjVOuCqLUPMYaaNi19RcDIH6x63I
	SMJfv7I3rBwUuQdgO6ubGRKJgXJQudrbPAJxkoeLscmwsB+wqt6d9VfBupcbBIRF8DOnTFmXJa3
	hVyZWxOWlxp57dTgvyiDDs6Vb7wCpUjAJCmGXR6dWar+32PFPj9lHKhcTcJu1F0vK2Lj++qZKSZ
	ilr1IMHAcr1Zx5diwu6zdckYlRgEVXvXgUEGX/8T4N1h4JPk/JmVkkVUpJyA1y0nyfx7dfaOi07
	GYUn91p+VsDYeyaLEB1OOGgd8wK8iHzOVi6A3HOoWuNU6HvQ1xZ44klauwY0arxtuXHGhnhc+sx
	2AMIxe78cE5T/Jg3s5PrbFYakwWjeqHlUr9SqRdtUpRgrsUYEfzMMVm5hEerUSCYjimoCmMJT
X-Google-Smtp-Source: AGHT+IF5qYeK0UbUxWYC9IlWRcaPj6pzLyL9bDYToDewGqEYc8L0CUlZiRY9pupXnoDGMdN9J7RKPA==
X-Received: by 2002:a17:907:7ea3:b0:afe:8b53:449c with SMTP id a640c23a62f3a-b04b1687e42mr1032793866b.34.1757440240499;
        Tue, 09 Sep 2025 10:50:40 -0700 (PDT)
Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com. [209.85.218.49])
        by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b078340e49csm25340066b.98.2025.09.09.10.50.38
        for <io-uring@vger.kernel.org>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Tue, 09 Sep 2025 10:50:38 -0700 (PDT)
Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-b02c719a117so1051751166b.1
        for <io-uring@vger.kernel.org>; Tue, 09 Sep 2025 10:50:38 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCXof1m7/6x4LJV92J3y6xOFd3/47TjZsZBha/ZELYZOc0As1AXuVg1FrqvlYEccjlGBWOe3+FRo8g==@vger.kernel.org
X-Received: by 2002:a17:906:6a1d:b0:b04:4175:62f7 with SMTP id
 a640c23a62f3a-b04b1687ceamr1313344566b.33.1757440237933; Tue, 09 Sep 2025
 10:50:37 -0700 (PDT)
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur> <68bf3854f101b_4224d100d7@dwillia2-mobl4.notmuch>
 <5922560.DvuYhMxLoT@rafael.j.wysocki> <20250909071818.15507ee6@kernel.org>
 <92dc8570-84a2-4015-9c7a-6e7da784869a@kernel.dk> <20250909-green-oriole-of-speed-85cd6d@lemur>
 <497c9c10-3309-49b9-8d4f-ff0bc34df4e5@suse.cz> <be98399d-3886-496e-9cf4-5ec909124418@kernel.dk>
 <CAHk-=whP2zoFm+-EmgQ69-00cxM5jgoEGWyAYVQ8bQYFbb2j=Q@mail.gmail.com> <af29e72b-ade6-4549-b264-af31a3128cf1@sirena.org.uk>
In-Reply-To: <af29e72b-ade6-4549-b264-af31a3128cf1@sirena.org.uk>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 9 Sep 2025 10:50:20 -0700
X-Gmail-Original-Message-ID: <CAHk-=wiN+8EUoik4UeAJ-HPSU7hczQP+8+_uP3vtAy_=YfJ9PQ@mail.gmail.com>
X-Gm-Features: AS18NWBdgXLEGA42KiP7hBpdYuD5iEhjlm5va7PappHV7NFwUOo9aBTGKqi-tac
Message-ID: <CAHk-=wiN+8EUoik4UeAJ-HPSU7hczQP+8+_uP3vtAy_=YfJ9PQ@mail.gmail.com>
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for 6.17-rc5)
To: Mark Brown <broonie@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>, Vlastimil Babka <vbabka@suse.cz>, 
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>, Jakub Kicinski <kuba@kernel.org>, 
	"Rafael J. Wysocki" <rafael@kernel.org>, dan.j.williams@intel.com, 
	Caleb Sander Mateos <csander@purestorage.com>, io-uring <io-uring@vger.kernel.org>, 
	workflows@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"

On Tue, 9 Sept 2025 at 10:08, Mark Brown <broonie@kernel.org> wrote:
>
> That works great for pull requests, but it's not so useful for a random
> patch like 5f9efb6b7667043527d377421af2070cc0aa2ecd

Sure it is.

The one-liner is just different. Use the patch-id instead. See Dan's
email - and the whole long discussion about how lore *ALREADY* has
most of this support.

Yeah, the patch-id command is admittedly a bit more esoteric than just
looking up the merge parent commit.

Using "git rev-parse" is already a bit obscure (although honestly,
it's a really useful command, and I actually do use it somewhat
regularly from the command line).

Using "git patch-id" is definitely in the "write a script for it"
category. I don't think I've ever used it as-is from the command line
as part of a one-liner. It's very much a command that is designed
purely for scripting, the interface is just odd and baroque and
doesn't really make sense for one-liners.

The typical use of patch-id is to generate two *lists* of patch-ids,
then sort them and use the patch-id as a key to find commits that look
the same.

That hopefully explains why the patch-id behavior is so odd, and not
really suited for using directly on the command line.

But my point is that we really have the infrastructure already in
place, and it's better than hardcoding some broken link into commits.

Now, I don't have that commit you mention (I assume it's some recent
commit in your own tree), but I picked a random commit from my
top-of-tree that contains one of those useless links, and look here:

   patchid=$(git diff-tree -p fef7ded169ed7e133612f90a032dc2af1ce19bef
| git patch-id | cut -d' ' -f1)
   firefox http://lore.kernel.org/all/?q=patchid:$patchid

and it's right there. It finds the stable tree backport too, and if
there had been multiple versions of the same patch posted, it would
have found the history of it all too.

Look, I readily admit that I would never write that as a one-liner. In
fact, I got it wrong the first time - I don't use 'cut' often enough,
and I forgot that the default delimeter is 'tab', not space, and got
garbage.

So that 'patch-id' generation line is just crazy line noise. I'm *not*
suggesting you do that.

But this kind of thing is literally what I'm talking about when I say
"maybe we could add a few scripts to support what you are doing".

                 Linus

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com [209.85.210.173])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id F004B31D384;
	Tue,  9 Sep 2025 17:56:38 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.173
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757440600; cv=none; b=WAD7X0ToR6Umc0qFciIUAYB0+eYiiFxNCTI7QMyTaTidBbx/3+kA2E2cbITq4V0vXffhzqgL8ty1bW2QOe243IqX8EoZz6msy7WzKB9IRhwBEtWBND/ZWlw5d0gnFJTkGNKDsmYOV5W5n/JEeznA0+PbTmZd30TkswO4TekZpU4=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757440600; c=relaxed/simple;
	bh=Ol+uKe6MO+Z4Uhwd1isDJiAM1ZoehnPeBQlCs5kn2CY=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=SGwGnMn5NSdk5KocGKEupVW6xhCcbuGDzZkRGfAoOYiJEb3EgQkh3EscjYxZEm7xoHgekLCsrt37mx4RKDB+kJ2nFEhG75luDULQJFR5vJudJGc+T8e+NFjf5iUpF5/qK82gwlq8icmbFfMLG+FfWo1Le2GY6CyYRfGouHWsd+4=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=gWbRa9QP; arc=none smtp.client-ip=209.85.210.173
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="gWbRa9QP"
Received: by mail-pf1-f173.google.com with SMTP id d2e1a72fcca58-772488c78bcso5790193b3a.1;
        Tue, 09 Sep 2025 10:56:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757440598; x=1758045398; darn=vger.kernel.org;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=qCCZb1yovZxeWDy2yNUvuBROJlg109CH/A8BUPdY4Bo=;
        b=gWbRa9QPCR+mw6wNJvzer9Znsi1xrqiQyFSz9E+jI3swudMgsra+AaEGIgHn9CnqZm
         BzjyMxxc5PX+mGdcUl2vW/VEZRTyecgSuGCEmzYS8+8VIpVA20v70JbG3o4CP3ji2n0E
         1S/QBzgM+C94wYsF+4Uhc+YnFBqht9PEiOTwRDntHUAFpOSfAKx26G1uCagQFAalrFmB
         sfkhZIumJwXwdB3wh7YfHywg3Aob3E7GhD380OzS5e2akFeiadEhzkX9IKrnBhyqQjUR
         SvxSz237xldmQrWhXE7lK/TEdv3+Il/gzkXexl35TSuSH2PnMf2iJaxmqMeTYTl6MWxq
         X7Iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757440598; x=1758045398;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=qCCZb1yovZxeWDy2yNUvuBROJlg109CH/A8BUPdY4Bo=;
        b=OkCyITkT1U4TJSzqWWJKWJlFsESsaNq/INnWPas3HMcnV7WjJgom8fw41FhJ23UIEH
         E2+LpJy6d4fabRK+epjFyzOCY8qtnz7ldkE7m1ncmW9tXSGfQ/SMYTHWyY2vcDDveSpc
         bVnUa789lRK84LbCnmQtabFYEmpNl0oIvleBR0ZckieOOFU0tNurDSx8jhrx/hgJtEvp
         sT5Iz3UL9ouUbzl/an0z583NONjxehSNGnv66Z3yWfrA+HLRrrpGL95X2A7HK2ZX1kZr
         PMGOGlrUiaTcJZnhehiIZ/W+2Yq7Som5VUQbRTVDKEVAe3v6xE9d6F+1to0F5k7FXLT7
         GULw==
X-Forwarded-Encrypted: i=1; AJvYcCX2bHA9TQ+dbpNrhvlKp0KS2RiVS5yx11+bKLCksDtxrreKGL6U6P4h6HTAHnkbcaAF7DTOJ5PrSB93@vger.kernel.org, AJvYcCXEVBgYu8eYEjaB/6/Om5PW0Qe1AJqxFNOG07jtNjAP983FU3/S278O5Y6QwTySLQWUlqFCCyp2Jw==@vger.kernel.org
X-Gm-Message-State: AOJu0YyYPn3iBVPpixP1RVfgj3CmR7xpW0KL6g52nSwYjtggDhVoIFOJ
	c2ZFBLGtWXwGBPKLVq7HVnCD59nWspmqDvKvJ7nhTu1tYyCvixNQUWfT
X-Gm-Gg: ASbGncsqvV2pWnR5tRhrnAY1E1B6maUt9FQFikMgP0PK5l71A0ETrh+gBBR052mrIF3
	Es6P08enzz3j3D30f54sXeSbzZ3NNpSwF7nOy6S/H8bJ3QK3MwVKnVdJFx0dW0eP1JKoWIXS/uR
	1jfPUQ+QsraMWg1aHgI6L2Ce6Ml/g0UbbOsD7zgK5c0wKRuWaKDTTrn3S2y61u3vb6BhpvCRFii
	wWYMXW5SA/+EYWsnxXbPhxKU1e4dLqgOI0DhUNhrJMSgUyA1Tg3r1Olrr/8potR0HucnEl5CqNR
	gv1SgMnkpde6a9TA5l7hY+ZItl9xdMsFSm0gBPjvJFWKC7JmYadBqBDUG9+DiHuhWR9CDjxkCSL
	N4tIjatrkRL0VraSlzwb0IURezJl/UVQ533ufJVbhmQ==
X-Google-Smtp-Source: AGHT+IGNqvhOu/ngQKCsJlPls2q5/T6BagRyNYXrvZ6qTiBs0qvJE4an9yUSV18OhTIWJBOrex/2cw==
X-Received: by 2002:a05:6a00:23d1:b0:770:56bf:ab5a with SMTP id d2e1a72fcca58-7742def592cmr14959182b3a.19.1757440598009;
        Tue, 09 Sep 2025 10:56:38 -0700 (PDT)
Received: from ast-mac ([2620:10d:c090:500::5:bbe5])
        by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7746615433asm2735987b3a.38.2025.09.09.10.56.36
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 09 Sep 2025 10:56:37 -0700 (PDT)
Date: Tue, 9 Sep 2025 10:56:32 -0700
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: dan.j.williams@intel.com
Cc: Linus Torvalds <torvalds@linux-foundation.org>, 
	Jens Axboe <axboe@kernel.dk>, Vlastimil Babka <vbabka@suse.cz>, 
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>, Jakub Kicinski <kuba@kernel.org>, 
	"Rafael J. Wysocki" <rafael@kernel.org>, Caleb Sander Mateos <csander@purestorage.com>, 
	io-uring <io-uring@vger.kernel.org>, workflows@vger.kernel.org
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
Message-ID: <u7jigxix5g3l274ciqkrcvg64fnrqute4vaiwn4tftfzs3cwzv@o4fyr7guogzj>
References: <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <68bf3854f101b_4224d100d7@dwillia2-mobl4.notmuch>
 <5922560.DvuYhMxLoT@rafael.j.wysocki>
 <20250909071818.15507ee6@kernel.org>
 <92dc8570-84a2-4015-9c7a-6e7da784869a@kernel.dk>
 <20250909-green-oriole-of-speed-85cd6d@lemur>
 <497c9c10-3309-49b9-8d4f-ff0bc34df4e5@suse.cz>
 <be98399d-3886-496e-9cf4-5ec909124418@kernel.dk>
 <CAHk-=whP2zoFm+-EmgQ69-00cxM5jgoEGWyAYVQ8bQYFbb2j=Q@mail.gmail.com>
 <68c062f7725c7_75db100eb@dwillia2-mobl4.notmuch>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <68c062f7725c7_75db100eb@dwillia2-mobl4.notmuch>

On Tue, Sep 09, 2025 at 10:25:11AM -0700, dan.j.williams@intel.com wrote:
> Linus Torvalds wrote:
> > On Tue, 9 Sept 2025 at 07:50, Jens Axboe <axboe@kernel.dk> wrote:
> > >
> > > I think we all know the answer to that one - it would've been EXACTLY
> > > the same outcome. Not to put words in Linus' mouth, but it's not the
> > > name of the tag that he finds repulsive, it's the very fact that a link
> > > is there and it isn't useful _to him_.
> > 
> [..]
> > Honestly people. Stop with the garbage already, and admit that your
> > links were just worthless noise.
> > 
> > And if you have some workflow that used them, maybe we can really add
> > scripting for those kinds of one-liners.
> > 
> > And maybe lore could even have particular indexing for the data you
> > are interested in if that helps.
> > 
> > In my experience, Konstantin has been very responsive when people have
> > asked for those kinds of things (both b4 and lore).
> 
> Hmm, good point. Lore does have patchid indexing. This needs some more
> cleanup but could replace my usage of patch.msgid.link.
> 
> firefox http://lore.kernel.org/all/?q=patchid%3A$(awk '{ print $1 }' <<< $(git patch-id --stable <<< $(git show $commit)))
> 
> Now, it does drop one useful feature that you know apriori that the
> maintainer did not commit a private version of a patch. However it
> should work in most cases.

It doesn't work reliably. Often enough maintainers massage the patch
a bit while applying to fix minor nits and patch-id will be different.
Here is just one such example:
c11f34e30088 ("bpf: Make update_prog_stats() always_inline")
and the commit includes the lore link to the original patch and
the comment how I tweaked it while applying:
https://lore.kernel.org/all/20250621045501.101187-1-dongml2@chinatelecom.cn/
git patch-id cannot find it:
https://lore.kernel.org/all/?q=patchid%3Afa0565c81e53682a83f4a0e6699c5664c53cda27

Linus's q=$(git rev-parse e9eaca6bf69d^2) trick worked because pr-tracker-bot
replied. That bot is not reliable either. Often enough we mark patches
in patchwork manually, because tracker missed them.

Really, there is no way for automation to detect the connection between
commit that landed in the tree and the original email unless git hooks
add something to the commit. Right now Link tag is that connection.

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id B10151D5CD1
	for <io-uring@vger.kernel.org>; Tue,  9 Sep 2025 17:59:12 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.52
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757440754; cv=none; b=UJpYljbXHTuqwHZvfWInXvtxzqs1z+77vdilEtbaxpArutTtmxR2eEc4PP/je//HGp42V5O54tQZvZL0N6WwhWPEMn3hyre/8CCjrMY5LK3vfbL8olXrtKt3s8xpqF05pHswFKLtr/t+4mohAB8WeSt3bXSRyk/8ZPHgiMIQP18=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757440754; c=relaxed/simple;
	bh=c9VmzZbrc+pRtYtQeM+DaVC2B+e5eMlSmeSeLCvR8cc=;
	h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
	 To:Cc:Content-Type; b=j5BNqhfWh+bEUZMIh+K0tCbau9HIt+LN32KuQCf4GFn58DGGIPXCTTsD0oqym90sdyDDyjui4oZIXxBV3KVUDKj6AIVKQ0eqLpjkbTU2fGpaclPaWdTSK2RnHvK7yYdGs/MzGZj+kQQyufndxQMqyOkeHWi3q0peZb53pJ85Axw=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org; spf=pass smtp.mailfrom=linuxfoundation.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=Ypbez8D+; arc=none smtp.client-ip=209.85.208.52
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linuxfoundation.org
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="Ypbez8D+"
Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-61d3d622a2bso9625999a12.0
        for <io-uring@vger.kernel.org>; Tue, 09 Sep 2025 10:59:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linux-foundation.org; s=google; t=1757440751; x=1758045551; darn=vger.kernel.org;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=urPTHi+HPKECqvpnFYRbpEebbKe2TRaFUwc8ISijTfs=;
        b=Ypbez8D+DGNbH51MrDtf8znbtU2dPqE/VEZEP3Z03VF+4vo6a3niW/+rZzIZ1Hf+DN
         1Wlw5GdIFWrZEV/X/6Y9r9xgp0qalETFXe2zRZgMaXZ2u4ZNzL09HmtNtRN5nwWMiro7
         8i6+W322T8kuIc642DjTNwF6amtdUXRc0+V5s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757440751; x=1758045551;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=urPTHi+HPKECqvpnFYRbpEebbKe2TRaFUwc8ISijTfs=;
        b=smHUyOmlxrJreeerJ8MSqAz+MLt0PaTkKuv6yG/1b4tH3yhgSkgtq3MXAinJUEvUJY
         4d2DRXgkrbzZM4eWJC8SFbgZ4v6EMzzh2nzgZ/8IfNzrJvGxwIvRRUOeCptvZVN9Tu2U
         ymVaLkFPe4C3JhVNy8y5Mlju2jGCqKvW++gE8izguOJMUO4Kk7AycFfhGX02pSmY2dkc
         e2oO7GrLiSv57YbCEwvXtxfHvjxvPqSdse+BX384u42HSRO5oWDUqV1+GUrfZEtgq1jH
         mWDnsiJVpT0sS2CODDnqVQ4fOLw1KdI/ARDn61/ownKBdvnawlothG7chWUUr7ZmUTG/
         6jBA==
X-Forwarded-Encrypted: i=1; AJvYcCWeZi0EdKNqLFTtU6SW/O95hhiCwFH0GimcEn3tR4E5zkrg7jkQ9eLUxblJpwNBK2q1+/7dsYHJ+Q==@vger.kernel.org
X-Gm-Message-State: AOJu0YyWCQerl2lACoCJotMdeXbbXSijhXV8nkxUaUTInZ86V700h5Ld
	Tqlxsl6AQU9d5Yq2ZVglfOQVLlePnTA2OCnUkFpIzHHDL0a+jY8uPKzpvaDbopFdi5Br0JaE8va
	Rk0b9plA=
X-Gm-Gg: ASbGncuR3VS9FoUQ3ibLDVgcoDXhdEZ4GTatG5ynN4DZeaTQOL+vvrdSwlt9s/eywbV
	bZupGBckrvMyKnDLBjHgzfW10SvyrP1Pgp28IXk9xjbMDTJCO36SNjuJ8Q6eGKo75MVvgfyDZ7i
	c4yfaKdstKF7/SDmtj+y706LqWhSyxyhILTrP9LlZEY0NLG2bYwZWsEyhc2bzBUmlKihjkuYCmP
	8qJpP2jfb7/7kyASb9ROEyvU7SidqUfFnPVkqxa5y7L2nc9llnoFBDfiFX7xTuUm1P6CcAw2zd2
	OGA617jDD2G+YeBKAYzy0DVxDUkVOVnYLCgYQ6vszu/CYjbihwNOTVRMJuWh7Rp4nT+AWWg/t60
	OyYtXZvxXutisjQ8euWAbtXFh01Zo8n3CY4Y76gyrvhRVqOeLDzkjemjmZbril2VpE7O+sA3OrX
	y4bz35SDg=
X-Google-Smtp-Source: AGHT+IEkqDCuIq2q2VFj5Ifly1AzsrWRoo79vZN3BRwDgiCcSm9o8Xg0x4MJUGYIxzCEgb1WnZnFcA==
X-Received: by 2002:a17:906:eec3:b0:b04:6c7a:dd0a with SMTP id a640c23a62f3a-b04930ab605mr1711468566b.8.1757440750630;
        Tue, 09 Sep 2025 10:59:10 -0700 (PDT)
Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com. [209.85.218.51])
        by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b07830a460bsm27822166b.23.2025.09.09.10.59.09
        for <io-uring@vger.kernel.org>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Tue, 09 Sep 2025 10:59:09 -0700 (PDT)
Received: by mail-ej1-f51.google.com with SMTP id a640c23a62f3a-b00a9989633so242930266b.0
        for <io-uring@vger.kernel.org>; Tue, 09 Sep 2025 10:59:09 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCW4NvECZ0s9S1BHDVzbwgdxj6fiG4BHK/0iablCGBJVIfIDmYy1D7m7k7YhuZsdJbqh5onBfUSkcA==@vger.kernel.org
X-Received: by 2002:a17:907:cd07:b0:b04:3402:391c with SMTP id
 a640c23a62f3a-b0493245ddbmr1713526366b.24.1757440749500; Tue, 09 Sep 2025
 10:59:09 -0700 (PDT)
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur> <68bf3854f101b_4224d100d7@dwillia2-mobl4.notmuch>
 <5922560.DvuYhMxLoT@rafael.j.wysocki> <20250909071818.15507ee6@kernel.org>
 <92dc8570-84a2-4015-9c7a-6e7da784869a@kernel.dk> <20250909-green-oriole-of-speed-85cd6d@lemur>
 <497c9c10-3309-49b9-8d4f-ff0bc34df4e5@suse.cz> <be98399d-3886-496e-9cf4-5ec909124418@kernel.dk>
 <CAHk-=whP2zoFm+-EmgQ69-00cxM5jgoEGWyAYVQ8bQYFbb2j=Q@mail.gmail.com>
 <af29e72b-ade6-4549-b264-af31a3128cf1@sirena.org.uk> <CAHk-=wiN+8EUoik4UeAJ-HPSU7hczQP+8+_uP3vtAy_=YfJ9PQ@mail.gmail.com>
In-Reply-To: <CAHk-=wiN+8EUoik4UeAJ-HPSU7hczQP+8+_uP3vtAy_=YfJ9PQ@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 9 Sep 2025 10:58:53 -0700
X-Gmail-Original-Message-ID: <CAHk-=wh2F5EPJWhiEeW=Ft0rx9HFcZj2cWnNGh_OuR0kdBm8UA@mail.gmail.com>
X-Gm-Features: AS18NWCMkQq-AHmRvXW3fe5pqZS6l4P8uIcvsgrr_gFx3AOIK1O6iaGHEGYcUd4
Message-ID: <CAHk-=wh2F5EPJWhiEeW=Ft0rx9HFcZj2cWnNGh_OuR0kdBm8UA@mail.gmail.com>
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for 6.17-rc5)
To: Mark Brown <broonie@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>, Vlastimil Babka <vbabka@suse.cz>, 
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>, Jakub Kicinski <kuba@kernel.org>, 
	"Rafael J. Wysocki" <rafael@kernel.org>, dan.j.williams@intel.com, 
	Caleb Sander Mateos <csander@purestorage.com>, io-uring <io-uring@vger.kernel.org>, 
	workflows@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"

On Tue, 9 Sept 2025 at 10:50, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>    patchid=$(git diff-tree -p fef7ded169ed7e133612f90a032dc2af1ce19bef
> | git patch-id | cut -d' ' -f1)

Oh, and looking more at that, use Dan's version instead.  You almost
certainly want to use '--stable' like Dan did, although maybe
Konstantin can speak up on what option lore actually uses for
indexing.

And you *can* screw up patchid matching. In particular, you can
generate patches different ways, and patch-id won't generate the same
thing for a rename patch and a add/delete patch, for example (again:
the traditional use case is that you generate the patch IDs all from
the same tree, so you control how you generate the patches)

But patch-ids are an underrated feature. They are actually lovely, and
git uses them under the hood for rebases etc.

             Linus

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6115627FB18
	for <io-uring@vger.kernel.org>; Tue,  9 Sep 2025 18:01:40 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.43
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757440902; cv=none; b=oMk6jfDw3OV/IMyNeqRSDFYMxQIwZYLrG6qirJ9QCsvagbohEprO7AUtF2MjO0YOeTHc5xN+iTKdZVmhhZgZNQzVAU2jONkjfkkw2wyiANB01isILVKuO39hBOrIi3cL+qCQsF/fN6PPmJWI5kUx+GdnBAgwwFMB8CslmobulCk=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757440902; c=relaxed/simple;
	bh=4jJ4vwrQYkp+N2xPfsd7uVQnm/Gczem/KStAtQyWA98=;
	h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
	 To:Cc:Content-Type; b=ZaafD1kKEjeZFMAI8OcNpCBI/FTFLdBmurEXP7onP3WKmbUwOZIg+7lVILQPAOYXkBdHrcD3U+qAcHQQ9oPyUP7EdoEI3US7le02yre++00nNdjHDVccbHTgyWzy7aUW6PtdeP/4tw8EUrRkKaW4i5lSYwbD9+y4wnit9XDyv2A=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org; spf=pass smtp.mailfrom=linuxfoundation.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=WJItl7ZR; arc=none smtp.client-ip=209.85.208.43
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linuxfoundation.org
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="WJItl7ZR"
Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-6188b72b7caso6576284a12.2
        for <io-uring@vger.kernel.org>; Tue, 09 Sep 2025 11:01:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linux-foundation.org; s=google; t=1757440898; x=1758045698; darn=vger.kernel.org;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=WGm5La2YGqWzfG7qHzDYQ/vd43mSA6C56DkDIwtwe8w=;
        b=WJItl7ZRnZVM6vjpVZtUzO64Vy7OcmXEk++k4pDMivfVu2V90ZPTCRJkUP+8rxOhYe
         QkMCPx6DmCLo1yNHI6EM39vubVzanBjNyIyms+dFF6wRhEcPSyTXzGf16GyGQsHJwY2k
         UBShaU5CKqPowacSnN6ikQmpKb9iV5586cV94=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757440898; x=1758045698;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=WGm5La2YGqWzfG7qHzDYQ/vd43mSA6C56DkDIwtwe8w=;
        b=CaGdoMWhO781WebXjwXC4V77WnsAlQN82uFSfOiaq0A2J7jGKKeWdyOKFoJXftMrUM
         2TgDlayn6NBf2q9g5KN7X+XE7eputAzg0E98GkLky7d+EJmn2Zy1Br76GDi8TCGqFk9H
         RnVlYUWN1stUsTZ2Phrl9bxD16wiol/6P94mvoKSBLZ/ygpR5Pr9mWDsDb9gKxZjhxac
         T2yqyquF30bpvv/xSpkIsjQrJtwZjw+jqiCBnPsTKwBzmefmIexBlE9cCY9jawUh2RUN
         YwdIC/seuMSzs7VAZ1kmZiV5i9DvbImbUbqzNvKEhhi3XBnORNvmVz71QW3c5Wj/zPEa
         EY1A==
X-Forwarded-Encrypted: i=1; AJvYcCUWmjLtZ4bj/3bap7G5H2y4L/5P3KHkH0Vq/0zL+D/M+UKDgVUph4t9frOptStAR5HOPiWIVmPQYw==@vger.kernel.org
X-Gm-Message-State: AOJu0YxLEtm7Zn9UYJmdkQRzs/upm7ury72hRcvZA1CU01YHFE6PEwAY
	O5acOq4aAaM8gd2NjlhkYCUSdotZWy/Xy4sbz1pIcL5/ZaxgenyEuxazqItETuyidhfLDCSpP7K
	K8RxKppU=
X-Gm-Gg: ASbGncuzPz5DyF78cl+Yx4aNLF6QK4hYNeKCv1HvWMtBqHws2pijTsia1nAkyXD011x
	pZiZbYk2pvXiW7YxjFqeLWbJO2jmghM2G57yPIgFuhPgvx1soxmBzSUV35KfC1ighdUpT1l0oxx
	oKqDmRn9dsF0Mq391sPLZa5aXwC6nFM/JpajFo74EkzbvqhLTqP9QQTik2jWS9odk1sL9u3R0Kw
	mujRMm9uPeYoM/RwlzLnbTguwxCW/dsqN3EI+UJAvbgKJNhhhg6/X4zK31ynXXpeKyow92UCclc
	MsH7flrkf7dC+sa325jifu+kvJTqCK5mZakPdSZArre72/GcsFRn/m6KWR8DkVLuDSDBnd7wAgn
	6DfnL5xzGeQdm2Mhfq/HAdfA8/ZDduvFTrJPM20c/7kWf8aKgt/lNAH9F2IgOq3jeJ/4Sg0Aq
X-Google-Smtp-Source: AGHT+IGMP8QjMwm4uB7iSpXSYjig/sBmeSDBLknlxl0I0bvuUYkuh9n1SQC2fYpi5P599mwIw7Tu6Q==
X-Received: by 2002:a17:906:fd82:b0:b04:71b1:7688 with SMTP id a640c23a62f3a-b04b16c3e04mr1111177266b.52.1757440898431;
        Tue, 09 Sep 2025 11:01:38 -0700 (PDT)
Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com. [209.85.218.49])
        by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b07833ac50asm26953466b.80.2025.09.09.11.01.37
        for <io-uring@vger.kernel.org>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Tue, 09 Sep 2025 11:01:37 -0700 (PDT)
Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-afcb7ae6ed0so934861766b.3
        for <io-uring@vger.kernel.org>; Tue, 09 Sep 2025 11:01:37 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCUgllvY6RTHl+r/MyzK9MvD3uTp22lkiXFYNQ5N7dX74DPvr71xI+s+LcTs8Md3qZ3W1H+qoCBhzg==@vger.kernel.org
X-Received: by 2002:a17:907:3e8c:b0:b04:522c:e0f7 with SMTP id
 a640c23a62f3a-b04b16bf0fcmr1058187066b.47.1757440897220; Tue, 09 Sep 2025
 11:01:37 -0700 (PDT)
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
References: <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <68bf3854f101b_4224d100d7@dwillia2-mobl4.notmuch> <5922560.DvuYhMxLoT@rafael.j.wysocki>
 <20250909071818.15507ee6@kernel.org> <92dc8570-84a2-4015-9c7a-6e7da784869a@kernel.dk>
 <20250909-green-oriole-of-speed-85cd6d@lemur> <497c9c10-3309-49b9-8d4f-ff0bc34df4e5@suse.cz>
 <be98399d-3886-496e-9cf4-5ec909124418@kernel.dk> <CAHk-=whP2zoFm+-EmgQ69-00cxM5jgoEGWyAYVQ8bQYFbb2j=Q@mail.gmail.com>
 <68c062f7725c7_75db100eb@dwillia2-mobl4.notmuch> <u7jigxix5g3l274ciqkrcvg64fnrqute4vaiwn4tftfzs3cwzv@o4fyr7guogzj>
In-Reply-To: <u7jigxix5g3l274ciqkrcvg64fnrqute4vaiwn4tftfzs3cwzv@o4fyr7guogzj>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 9 Sep 2025 11:01:20 -0700
X-Gmail-Original-Message-ID: <CAHk-=winCxfCXfTgjfhdqkp2EXrx7fbrGookkHuAtT3Lp5xT1w@mail.gmail.com>
X-Gm-Features: Ac12FXx5QpA-3kwbUKV6WpHs60phw1MkKolvZNXPDmgvvKpYtrNovzWPkJMVvUI
Message-ID: <CAHk-=winCxfCXfTgjfhdqkp2EXrx7fbrGookkHuAtT3Lp5xT1w@mail.gmail.com>
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for 6.17-rc5)
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: dan.j.williams@intel.com, Jens Axboe <axboe@kernel.dk>, 
	Vlastimil Babka <vbabka@suse.cz>, Konstantin Ryabitsev <konstantin@linuxfoundation.org>, 
	Jakub Kicinski <kuba@kernel.org>, "Rafael J. Wysocki" <rafael@kernel.org>, 
	Caleb Sander Mateos <csander@purestorage.com>, io-uring <io-uring@vger.kernel.org>, 
	workflows@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"

On Tue, 9 Sept 2025 at 10:56, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> It doesn't work reliably. Often enough maintainers massage the patch
> a bit while applying to fix minor nits and patch-id will be different.

Honestly, if you massage a patch you should probably mention it.

THAT is the kind of thing where it actually makes sense to say
"modified version of XYZ" and pointing to the original.

Look, at that point it's actually *IMPORTANT* to explicitly state that
you didn't actually apply the original patch.

This falls clearly under the "don't add links mindlessly, do it
mindfully" heading.

          Linus

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 615D334F465
	for <io-uring@vger.kernel.org>; Tue,  9 Sep 2025 18:06:59 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.135.223.130
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757441221; cv=none; b=Tz1ScHrYrlLrG2tEkEZrHqtLI2pnDBzB2xJva+2cwEMMdDqtSfdcI1oMiHZlQgOub+nW4qNj+bb+Jfc/WKAdJvsIyEqvwxHEarbxFXiKWQkdWmCRmbLak61Q0x96jb8Yv2aXOubagLhpNhPGB0do8lw8+gF+8xcttKPod9aMD0U=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757441221; c=relaxed/simple;
	bh=1PGprpfw/ha2Cq6RMLaVXkraMIMn0M/ii1ffuvUq1H0=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=r0C5Lot3aMB+9UDrMdG68HiFqmYlkbXYjmDbI3bT6oW8RsLqqVJXxNo5ekIK0Adrj/6z6/8S4NMXu9z9ktuMVmkj42wVM7ig6i6/3Zwga+Rur4cVJKiVVAa8PQmD9AEpIFEYIauvdSCUz9863KKaUPp9taMff9CEyDUblO2jpYY=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz; spf=pass smtp.mailfrom=suse.cz; dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b=FiLdhniQ; dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b=FFP/lEH2; dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b=FiLdhniQ; dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b=FFP/lEH2; arc=none smtp.client-ip=195.135.223.130
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.cz
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b="FiLdhniQ";
	dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b="FFP/lEH2";
	dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b="FiLdhniQ";
	dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b="FFP/lEH2"
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(No client certificate requested)
	by smtp-out1.suse.de (Postfix) with ESMTPS id 26AD822836;
	Tue,  9 Sep 2025 18:06:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa;
	t=1757441217; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=Am4xHpo/hojedBhPG2np8vTsGSiJVEKAPLsh1JPU6oY=;
	b=FiLdhniQtrLIz53MsZl5csVCv5a2tf0V8r4Ll6fkCYQbk/+owb/xFe93EGdB2Yqi3ZD+kQ
	mPU2eUSSGPUCJzyCMWSQFKAJIMIwESXJSKzEjSCizKs2ZbjgZERFN3pUE0lzzPC77Gckt3
	3RkHI5AS1jo7JPWWQu1PU+Yqcg3SQ+c=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz;
	s=susede2_ed25519; t=1757441217;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=Am4xHpo/hojedBhPG2np8vTsGSiJVEKAPLsh1JPU6oY=;
	b=FFP/lEH2QrOiAX3hhEykprIiCeIQqB+kDG+a7451AKeAGzmNvJO4UlE/R+9eQQIIlvLrfk
	26UdF1hFwAVA4gAQ==
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa;
	t=1757441217; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=Am4xHpo/hojedBhPG2np8vTsGSiJVEKAPLsh1JPU6oY=;
	b=FiLdhniQtrLIz53MsZl5csVCv5a2tf0V8r4Ll6fkCYQbk/+owb/xFe93EGdB2Yqi3ZD+kQ
	mPU2eUSSGPUCJzyCMWSQFKAJIMIwESXJSKzEjSCizKs2ZbjgZERFN3pUE0lzzPC77Gckt3
	3RkHI5AS1jo7JPWWQu1PU+Yqcg3SQ+c=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz;
	s=susede2_ed25519; t=1757441217;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=Am4xHpo/hojedBhPG2np8vTsGSiJVEKAPLsh1JPU6oY=;
	b=FFP/lEH2QrOiAX3hhEykprIiCeIQqB+kDG+a7451AKeAGzmNvJO4UlE/R+9eQQIIlvLrfk
	26UdF1hFwAVA4gAQ==
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(No client certificate requested)
	by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 053671365E;
	Tue,  9 Sep 2025 18:06:56 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
	by imap1.dmz-prg2.suse.org with ESMTPSA
	id uFuEO8BswGiZNQAAD6G6ig
	(envelope-from <vbabka@suse.cz>); Tue, 09 Sep 2025 18:06:56 +0000
Message-ID: <e09555bc-4b0f-4f3a-82a3-914f38c3cde5@suse.cz>
Date: Tue, 9 Sep 2025 20:06:56 +0200
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
Content-Language: en-US
To: Linus Torvalds <torvalds@linux-foundation.org>,
 Jens Axboe <axboe@kernel.dk>
Cc: Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
 Jakub Kicinski <kuba@kernel.org>, "Rafael J. Wysocki" <rafael@kernel.org>,
 dan.j.williams@intel.com, Caleb Sander Mateos <csander@purestorage.com>,
 io-uring <io-uring@vger.kernel.org>, workflows@vger.kernel.org
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <68bf3854f101b_4224d100d7@dwillia2-mobl4.notmuch>
 <5922560.DvuYhMxLoT@rafael.j.wysocki> <20250909071818.15507ee6@kernel.org>
 <92dc8570-84a2-4015-9c7a-6e7da784869a@kernel.dk>
 <20250909-green-oriole-of-speed-85cd6d@lemur>
 <497c9c10-3309-49b9-8d4f-ff0bc34df4e5@suse.cz>
 <be98399d-3886-496e-9cf4-5ec909124418@kernel.dk>
 <CAHk-=whP2zoFm+-EmgQ69-00cxM5jgoEGWyAYVQ8bQYFbb2j=Q@mail.gmail.com>
From: Vlastimil Babka <vbabka@suse.cz>
Autocrypt: addr=vbabka@suse.cz; keydata=
 xsFNBFZdmxYBEADsw/SiUSjB0dM+vSh95UkgcHjzEVBlby/Fg+g42O7LAEkCYXi/vvq31JTB
 KxRWDHX0R2tgpFDXHnzZcQywawu8eSq0LxzxFNYMvtB7sV1pxYwej2qx9B75qW2plBs+7+YB
 87tMFA+u+L4Z5xAzIimfLD5EKC56kJ1CsXlM8S/LHcmdD9Ctkn3trYDNnat0eoAcfPIP2OZ+
 9oe9IF/R28zmh0ifLXyJQQz5ofdj4bPf8ecEW0rhcqHfTD8k4yK0xxt3xW+6Exqp9n9bydiy
 tcSAw/TahjW6yrA+6JhSBv1v2tIm+itQc073zjSX8OFL51qQVzRFr7H2UQG33lw2QrvHRXqD
 Ot7ViKam7v0Ho9wEWiQOOZlHItOOXFphWb2yq3nzrKe45oWoSgkxKb97MVsQ+q2SYjJRBBH4
 8qKhphADYxkIP6yut/eaj9ImvRUZZRi0DTc8xfnvHGTjKbJzC2xpFcY0DQbZzuwsIZ8OPJCc
 LM4S7mT25NE5kUTG/TKQCk922vRdGVMoLA7dIQrgXnRXtyT61sg8PG4wcfOnuWf8577aXP1x
 6mzw3/jh3F+oSBHb/GcLC7mvWreJifUL2gEdssGfXhGWBo6zLS3qhgtwjay0Jl+kza1lo+Cv
 BB2T79D4WGdDuVa4eOrQ02TxqGN7G0Biz5ZLRSFzQSQwLn8fbwARAQABzSBWbGFzdGltaWwg
 QmFia2EgPHZiYWJrYUBzdXNlLmN6PsLBlAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIe
 AQIXgBYhBKlA1DSZLC6OmRA9UCJPp+fMgqZkBQJnyBr8BQka0IFQAAoJECJPp+fMgqZkqmMQ
 AIbGN95ptUMUvo6aAdhxaOCHXp1DfIBuIOK/zpx8ylY4pOwu3GRe4dQ8u4XS9gaZ96Gj4bC+
 jwWcSmn+TjtKW3rH1dRKopvC07tSJIGGVyw7ieV/5cbFffA8NL0ILowzVg8w1ipnz1VTkWDr
 2zcfslxJsJ6vhXw5/npcY0ldeC1E8f6UUoa4eyoskd70vO0wOAoGd02ZkJoox3F5ODM0kjHu
 Y97VLOa3GG66lh+ZEelVZEujHfKceCw9G3PMvEzyLFbXvSOigZQMdKzQ8D/OChwqig8wFBmV
 QCPS4yDdmZP3oeDHRjJ9jvMUKoYODiNKsl2F+xXwyRM2qoKRqFlhCn4usVd1+wmv9iLV8nPs
 2Db1ZIa49fJet3Sk3PN4bV1rAPuWvtbuTBN39Q/6MgkLTYHb84HyFKw14Rqe5YorrBLbF3rl
 M51Dpf6Egu1yTJDHCTEwePWug4XI11FT8lK0LNnHNpbhTCYRjX73iWOnFraJNcURld1jL1nV
 r/LRD+/e2gNtSTPK0Qkon6HcOBZnxRoqtazTU6YQRmGlT0v+rukj/cn5sToYibWLn+RoV1CE
 Qj6tApOiHBkpEsCzHGu+iDQ1WT0Idtdynst738f/uCeCMkdRu4WMZjteQaqvARFwCy3P/jpK
 uvzMtves5HvZw33ZwOtMCgbpce00DaET4y/UzsBNBFsZNTUBCACfQfpSsWJZyi+SHoRdVyX5
 J6rI7okc4+b571a7RXD5UhS9dlVRVVAtrU9ANSLqPTQKGVxHrqD39XSw8hxK61pw8p90pg4G
 /N3iuWEvyt+t0SxDDkClnGsDyRhlUyEWYFEoBrrCizbmahOUwqkJbNMfzj5Y7n7OIJOxNRkB
 IBOjPdF26dMP69BwePQao1M8Acrrex9sAHYjQGyVmReRjVEtv9iG4DoTsnIR3amKVk6si4Ea
 X/mrapJqSCcBUVYUFH8M7bsm4CSxier5ofy8jTEa/CfvkqpKThTMCQPNZKY7hke5qEq1CBk2
 wxhX48ZrJEFf1v3NuV3OimgsF2odzieNABEBAAHCwXwEGAEKACYCGwwWIQSpQNQ0mSwujpkQ
 PVAiT6fnzIKmZAUCZ8gcVAUJFhTonwAKCRAiT6fnzIKmZLY8D/9uo3Ut9yi2YCuASWxr7QQZ
 lJCViArjymbxYB5NdOeC50/0gnhK4pgdHlE2MdwF6o34x7TPFGpjNFvycZqccSQPJ/gibwNA
 zx3q9vJT4Vw+YbiyS53iSBLXMweeVV1Jd9IjAoL+EqB0cbxoFXvnjkvP1foiiF5r73jCd4PR
 rD+GoX5BZ7AZmFYmuJYBm28STM2NA6LhT0X+2su16f/HtummENKcMwom0hNu3MBNPUOrujtW
 khQrWcJNAAsy4yMoJ2Lw51T/5X5Hc7jQ9da9fyqu+phqlVtn70qpPvgWy4HRhr25fCAEXZDp
 xG4RNmTm+pqorHOqhBkI7wA7P/nyPo7ZEc3L+ZkQ37u0nlOyrjbNUniPGxPxv1imVq8IyycG
 AN5FaFxtiELK22gvudghLJaDiRBhn8/AhXc642/Z/yIpizE2xG4KU4AXzb6C+o7LX/WmmsWP
 Ly6jamSg6tvrdo4/e87lUedEqCtrp2o1xpn5zongf6cQkaLZKQcBQnPmgHO5OG8+50u88D9I
 rywqgzTUhHFKKF6/9L/lYtrNcHU8Z6Y4Ju/MLUiNYkmtrGIMnkjKCiRqlRrZE/v5YFHbayRD
 dJKXobXTtCBYpLJM4ZYRpGZXne/FAtWNe4KbNJJqxMvrTOrnIatPj8NhBVI0RSJRsbilh6TE
 m6M14QORSWTLRg==
In-Reply-To: <CAHk-=whP2zoFm+-EmgQ69-00cxM5jgoEGWyAYVQ8bQYFbb2j=Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spamd-Result: default: False [-4.30 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FUZZY_RATELIMITED(0.00)[rspamd.com];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_SEVEN(0.00)[9];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	DKIM_SIGNED(0.00)[suse.cz:s=susede2_rsa,suse.cz:s=susede2_ed25519];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	URIBL_BLOCKED(0.00)[kernel.dk:email,imap1.dmz-prg2.suse.org:helo,msgid.link:url,suse.cz:mid];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.cz:mid]
X-Spam-Flag: NO
X-Spam-Level: 
X-Spam-Score: -4.30

On 9/9/25 18:40, Linus Torvalds wrote:
> On Tue, 9 Sept 2025 at 07:50, Jens Axboe <axboe@kernel.dk> wrote:
>>
>> I think we all know the answer to that one - it would've been EXACTLY
>> the same outcome. Not to put words in Linus' mouth, but it's not the
>> name of the tag that he finds repulsive, it's the very fact that a link
>> is there and it isn't useful _to him_.
> 
> It's not that it isn't "useful to me". It's that it HURTS, and it's
> entirely redundant.
> 
> It literally wastes my time. Yes, I have the option to ignore them,
> but then I ignore potentially *good* links.
> 
> Rafael asked what the difference between "Fixes:" and "Cc: stable" is
> - it's exactly the fact that those do NOT waste human time, and they
> were NOT automated garbage.
> 
> The rules for those are that they have been added *thoughtfully*: you
> don't add 'stable' with automation without even thinking about it, do
> you?
> 
> And if you did, THAT WOULD BE WRONG TOO.
> 
> Wouldn't you agree?

I fully agree. Now the sad part of this example is that if one conciously
decides that the bug fixed is not critical enough according to the
documented stable rules, and doesn't add Cc: stable, there's a good chance
the AUTOSEL automation will pick it anyway, these days with a help of LLM.
> Dammit, is it really so hard to understand this issue? Automated noise
> is bad noise. And when it has a human cost, it needs to go away.
> 
> I'm not saying that you can't link to the original email. But you need
> to STOP THE MINDLESS AUTOMATION WHEN IT HURTS.
> 
> So add the link, by all means - but only add it when it is relevant
> and gives real information. And THINK about it, don't have it in some
> mindless script.

I'd hope that distinguishing the automated links from conscious one (i.e.
using the patch.msgid.link vs lore domains) would be enough to make everyone
happy without hurting. But fine.
> Because if it's in a mindless script, then dammit, the lore "search"
> function is objectively better after-the-fact. Really. Using the lore
> search gives the original email *and* more.
> 
> The same, btw, goes for my merge messages. No, I'm not going to add
> some idiotic "Link" to the original pull request email. Not only don't
> I fetch those from lore to begin with, you can literally search for
> them.
> 
> Look here, for the latest merge I did of your tree: e9eaca6bf69d.
Later in the thread patch-id is mentioned. I think it was mentioned in the
past threads that due to small context changes due to e.g. base that the
submitter used and the maintainer used to apply, and even diff algorithm not
being set in stone, they can't be made fully reliable?

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5C8762F4A;
	Tue,  9 Sep 2025 18:13:46 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.53
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757441628; cv=none; b=lbaiNlQXhemAtrhKsCMLv7N9tEarw6yuRJwMp9krzVTYgzf/ZA4FLuVdmCuRlzhPRsETxynoVIntnz3+W8BTtQwS9OsccYRz57IBIGtJ3jCN4IBhZHHKjsI7wFUZgLShwjOvQoTws1okKTDsL0r0fu5IUWJzwVIj+2KJjkfiJXs=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757441628; c=relaxed/simple;
	bh=v5MIgyNMcuVeoaHKE3jeJkB/cPJ+KgcPL9K1KGUT/k8=;
	h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
	 To:Cc:Content-Type; b=W9rwS9kUg/R5VishGb2jVJaxUKfEjlCn9Q2mTsajBqFbdu7K56bawNMzP86Hk9ysCrFjEQUxtjsfQ36Pwhi0t5xXdWvZGailUyH9rv+OBEpdjOE84tORBj4sItAqmJQBxISIArzpdADpt2b5USuZKxLyaPI/L8lhB3y1RFjl6Os=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=LX+FIajQ; arc=none smtp.client-ip=209.85.221.53
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="LX+FIajQ"
Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-3df2f4aedc7so3381520f8f.2;
        Tue, 09 Sep 2025 11:13:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1757441625; x=1758046425; darn=vger.kernel.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=v5MIgyNMcuVeoaHKE3jeJkB/cPJ+KgcPL9K1KGUT/k8=;
        b=LX+FIajQ5OjUSzsiavrNlsyr5HLxSzyzQmcmuJxfRLq9QXW6lE/IhuHywlaDXC8zMN
         Z5CnG7Gnyypb0ck1rndAOzgMhc1VJ3Pw52LtbzKcNO3VsLmJmVhJoVVL8Dmbc+08oh39
         1dwQaBjGhoJ21oteGNuFS6ZPz7zsU2BOKGLrgxSC6tPCATdlm9Gzk3DHn6M67Gy3JYWW
         8kmRpwdmBxBYXb6GHNRYosKU7vNxlGL2az42SS6ql9hBH0ewUjAhNniVPJnUVKyGRlIz
         LfbwdbV5LtYpNp5lD2QCILTJHQFqr5AD0wrZX9XfBnRPGtZUNZavRvcWZSQTdIg9056U
         K/1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757441625; x=1758046425;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=v5MIgyNMcuVeoaHKE3jeJkB/cPJ+KgcPL9K1KGUT/k8=;
        b=C+Kz+6Vw0gL8Tq+CZFJXQwUnBSxt4DjJQp52GqVqmacxzR9N9Xg447nWDx0gnthyq8
         I0fLXxZztjUzGNARAAuxVI16H45zO5h9noTcGeW03oxr0BeI2FFfoWXJRocb23CqN4VT
         +0DUsjCddYCv0TUsqPD1+F/17vyslTewbAkbEz2Haix2NMoCX70NfzGnHYDDAfI23Hss
         gzmxCpsWg1mTMplaogE98KWl9imi2KQT5lgl5FJ2Qsz4rVPvGMM4crrn/plyyswmGLwB
         Tn1u7X2uwBTsG8KV+crV453kq8gz8yZThMjxX67CuG9X4MO7H2UGLlrb4o3mXazTpFJY
         cgcw==
X-Forwarded-Encrypted: i=1; AJvYcCVuqt5q9vS+B9852UAHvq+bD9EO2g2do71mHMxClX6FnAN1wgzWxeDwPNvF4hs07O4B2lPiQqUBXA==@vger.kernel.org, AJvYcCX4Bj8Z5Dqj+EDrB3+MXYUcSQrOyZHrzwTsmJ7iMa/hFDOfq0zwgxTkBq1zkJbRjCCbilKQO9iI923T@vger.kernel.org
X-Gm-Message-State: AOJu0YzjbwBZHmcGMPSJwxJZu2eCsnevo5hhA+1Q5okjgh1KGjAo8pJq
	GrbACnJtPsSqyi55oAPh6WZ5WlbWkIyDRbZFw25vI5E/6qSMcwjr9s3qe9jfa9tKQxO6d70pgUU
	yd65cFRoRcchH/1mCpBc4W5bwA3DYxlE=
X-Gm-Gg: ASbGnculhQpogps6JpgmZ5+XXWUzDHMbCLZaFc9bDYqd93dklBg1ACCsu7mpx2BzKk6
	9mlAeWCT7NgBbPPqAs+cI5+ybs8DreM0M4MYs+pehag+ukHvbDIgpP8Cm0YcAJfJuuu0QqZyeWM
	rclIhp/OwcJTAuegNRFa/BbsYeNOxv8irQm1BRvLaobB14ylcmpAe+++5b1SHfXZHPhMXqxEp+Q
	KtJQGT4BSLkWgkkBiU7eS620agfQwbt1w==
X-Google-Smtp-Source: AGHT+IG69/CJrKJwYK4JKcm+s+1TRjF8ogI0fllaYgf11+PXm91pngy54nGXIr1gtbJ2ajS4oMoihnLsVSPRe5IbZgo=
X-Received: by 2002:a05:6000:4184:b0:3e7:d46:2f64 with SMTP id
 ffacd0b85a97d-3e70d4632a2mr10640424f8f.28.1757441624642; Tue, 09 Sep 2025
 11:13:44 -0700 (PDT)
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
References: <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <68bf3854f101b_4224d100d7@dwillia2-mobl4.notmuch> <5922560.DvuYhMxLoT@rafael.j.wysocki>
 <20250909071818.15507ee6@kernel.org> <92dc8570-84a2-4015-9c7a-6e7da784869a@kernel.dk>
 <20250909-green-oriole-of-speed-85cd6d@lemur> <497c9c10-3309-49b9-8d4f-ff0bc34df4e5@suse.cz>
 <be98399d-3886-496e-9cf4-5ec909124418@kernel.dk> <CAHk-=whP2zoFm+-EmgQ69-00cxM5jgoEGWyAYVQ8bQYFbb2j=Q@mail.gmail.com>
 <68c062f7725c7_75db100eb@dwillia2-mobl4.notmuch> <u7jigxix5g3l274ciqkrcvg64fnrqute4vaiwn4tftfzs3cwzv@o4fyr7guogzj>
 <CAHk-=winCxfCXfTgjfhdqkp2EXrx7fbrGookkHuAtT3Lp5xT1w@mail.gmail.com>
In-Reply-To: <CAHk-=winCxfCXfTgjfhdqkp2EXrx7fbrGookkHuAtT3Lp5xT1w@mail.gmail.com>
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Date: Tue, 9 Sep 2025 11:13:31 -0700
X-Gm-Features: AS18NWCcde3u6VnJ3IQPqJInT2PGGtXFf7eGHpXP9Gg3U1Fpz872BScmUYyp-9w
Message-ID: <CAADnVQKAR-MnALzJXdvdef4ftgMA1=Z_c4bnzep68yO20vLAow@mail.gmail.com>
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for 6.17-rc5)
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dan Williams <dan.j.williams@intel.com>, Jens Axboe <axboe@kernel.dk>, 
	Vlastimil Babka <vbabka@suse.cz>, Konstantin Ryabitsev <konstantin@linuxfoundation.org>, 
	Jakub Kicinski <kuba@kernel.org>, "Rafael J. Wysocki" <rafael@kernel.org>, 
	Caleb Sander Mateos <csander@purestorage.com>, io-uring <io-uring@vger.kernel.org>, 
	workflows@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Sep 9, 2025 at 11:01=E2=80=AFAM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Tue, 9 Sept 2025 at 10:56, Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > It doesn't work reliably. Often enough maintainers massage the patch
> > a bit while applying to fix minor nits and patch-id will be different.
>
> Honestly, if you massage a patch you should probably mention it.
>
> THAT is the kind of thing where it actually makes sense to say
> "modified version of XYZ" and pointing to the original.
>
> Look, at that point it's actually *IMPORTANT* to explicitly state that
> you didn't actually apply the original patch.

and I did in the email reply (as you could see in the lore link).
That's what we always do.
Email is the way to communicate such changes.
Sometimes we rewrite the commit log too to reduce verbosity,
fix typos or whatever. Without direct email reply developers
don't notice that commit was tweaked.

The point is that 'git patch-id --stable' is not reliable.

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 65DAB2F4A
	for <io-uring@vger.kernel.org>; Tue,  9 Sep 2025 18:14:41 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.53
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757441683; cv=none; b=A5G+LYI/BVBDv0whjUdZMU02JyoRDFF6Re4cGfZKmE258EDVFEQBa4co5u8pzmX8nwFRU4AdFqLEVXGcw0wCubcfoLCJqXn/uzQH75BhzfW1K4WYOGiUumVv3ZxxPkeq9jWpYIAD2GgpdFq+GcP2MQjgGfuHE2Aa7eulr59+UN0=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757441683; c=relaxed/simple;
	bh=uI1wjvIjVie1NesRLG312MngKxT3eOO8ZcLL/uPo1aE=;
	h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
	 To:Cc:Content-Type; b=Rxdk83jeUirshhS7eYzBXHo6HcujyEP4jVQ2u0lBRv2Y3fg++EiE4RHEwT047Ip0CnD2J9s0gEWSBuw3AWnK2IFHDKbRy/MZ0N1LslhWlR+eMq27So08tDw9+aNC3nesaUcIvBCvUTGf8Vjm9Y0h0xWXk5cB4syNvrvc02PjrmI=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org; spf=pass smtp.mailfrom=linuxfoundation.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=Pr0ujVPx; arc=none smtp.client-ip=209.85.208.53
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linuxfoundation.org
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="Pr0ujVPx"
Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-61cb4374d2fso8991554a12.2
        for <io-uring@vger.kernel.org>; Tue, 09 Sep 2025 11:14:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linux-foundation.org; s=google; t=1757441679; x=1758046479; darn=vger.kernel.org;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=vfO17BHW0rZfNCT/9fgYlAw+m8wHcd9WOi8933xChxE=;
        b=Pr0ujVPxUut2n+gUpYcLp9ufQo2akhalm3hFRK3QBBGXlD5CoWcogZJ09LbZ5hyTY6
         nAdgU1hAo8DvqJHChupnY3i5aiLBBhEHBxNYm1DJN65IYvDX14ymvzOuSI9EXn+9g/Lp
         EoyHVTrflYCkpeOLS3ePrwbsc0hiPyimCgpws=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1757441679; x=1758046479;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=vfO17BHW0rZfNCT/9fgYlAw+m8wHcd9WOi8933xChxE=;
        b=vDyMTOg3ULKpjQpb7yzkkp6l1hbmdpNbYlIhYFVCweYvi6Z2MZnKweznD34o59QYHu
         itgN6qhVZFsWQpND4IJy2bkenjD2tb02Bhux31H+6AnSwKCIyMq46UDNqFU5eQRI6Bvn
         j+1jKvoGPjGVJ0Kr1nf+02rMQX1fb5HjJB44CVwNTRtg6uhHFlxLcGzQPoaSvJGIh0us
         0H8IjOCKsiRka0f0FV5ZCJL0YyymP2/XTt8VbdjPdjbd+E2CoU77/dAeM+9ViAr21/5h
         DXAUDoD8nWZSWsqDY8HDG+7FKDswx/ubD/wcL25U7zMue1NRbrDZ0P261zX1khvgG963
         gGRg==
X-Forwarded-Encrypted: i=1; AJvYcCWDA1t1s+QFVm9isTUkUpGNT3HI7oqyG0aQUh80CDHOCqrZx2YTedB1TafmNfjyepW73HCnyQmniw==@vger.kernel.org
X-Gm-Message-State: AOJu0YzuDjHwhu3aElwwbFI3WhaEN+6hZfqeZDUKFVivkQ/j/N4brdOY
	O5mcVeFjZwtOmTSP9A5NcUId7e+ztGE7dvdt4OJpkUScllSYM/4kIvBL1n+N2qEbaqgEcmBWPM/
	EeXc7o9g=
X-Gm-Gg: ASbGncv7lGyQBLPps3JfIrMlw3q74qvtG/wZLEMBDyeMGAJjijKt7Dy8EeP2+r+DXnJ
	JKeBC6NvXvjnnilPo0JlNZ+UhgiwiJ88mPl/62qR3oy+o5t0K6uzgGtlWLMz64fxZMrh77SVC9o
	dEJZ2sYagnUAxn2FrcSCBnVpCMJfSeDmeR41Jfv9iosVZ6FKCm71HSicujL6SSnXDsBSXBC0FoL
	tfzSBxwK8f0xAd5/TYD+MpJ1ixEoz+HpS4nz6bKxjYGuD5wzIW95JcdkfeRDsGiUkqXr7EmuHDQ
	n2z4klHMzsPz8ItIzzN2h1qNb515Tm5NB96OOJrDlV9yUl2wgdhMwF0+QrbtHCmh/WuYD6w4Fhy
	dOslTky7NAbH8Vfu+4GlmgOQGVmRyCZW8T/WlV3vBOSz3yLGBYOGPhY9jYiLinekfQdV8v9uEFF
	Gv4APlyos=
X-Google-Smtp-Source: AGHT+IGEAjsB5+KLtTOe7DEwFnh/RKaDzVTwccmUADGa6pVJtC6gE7IRQs5slV8MJbItNj2gJlM5Cw==
X-Received: by 2002:a05:6402:3510:b0:625:fd40:c590 with SMTP id 4fb4d7f45d1cf-625fd40c6e4mr10492758a12.22.1757441679381;
        Tue, 09 Sep 2025 11:14:39 -0700 (PDT)
Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com. [209.85.218.48])
        by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-62c0123f23dsm1742094a12.25.2025.09.09.11.14.38
        for <io-uring@vger.kernel.org>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Tue, 09 Sep 2025 11:14:38 -0700 (PDT)
Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-b0411b83aafso979282666b.1
        for <io-uring@vger.kernel.org>; Tue, 09 Sep 2025 11:14:38 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCXRQLl1x8rUjU/gv8zZADceUJANd19wiuIuC4J9OvwdT8oPa1Y8+wDePXK+DpcfZMeoM235p8tnjQ==@vger.kernel.org
X-Received: by 2002:a17:907:9483:b0:b04:4786:5dfc with SMTP id
 a640c23a62f3a-b04b14aec52mr1479633666b.27.1757441677560; Tue, 09 Sep 2025
 11:14:37 -0700 (PDT)
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur> <68bf3854f101b_4224d100d7@dwillia2-mobl4.notmuch>
 <5922560.DvuYhMxLoT@rafael.j.wysocki> <20250909071818.15507ee6@kernel.org>
 <92dc8570-84a2-4015-9c7a-6e7da784869a@kernel.dk> <20250909-green-oriole-of-speed-85cd6d@lemur>
 <497c9c10-3309-49b9-8d4f-ff0bc34df4e5@suse.cz> <be98399d-3886-496e-9cf4-5ec909124418@kernel.dk>
 <CAHk-=whP2zoFm+-EmgQ69-00cxM5jgoEGWyAYVQ8bQYFbb2j=Q@mail.gmail.com> <e09555bc-4b0f-4f3a-82a3-914f38c3cde5@suse.cz>
In-Reply-To: <e09555bc-4b0f-4f3a-82a3-914f38c3cde5@suse.cz>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 9 Sep 2025 11:14:21 -0700
X-Gmail-Original-Message-ID: <CAHk-=wgfWG+MHXoFG2guu2GAoSBrmcdXU2apj+MJpgdCXxwbwA@mail.gmail.com>
X-Gm-Features: Ac12FXyIDqMJF8_mBB-HCaVHrznKHzDDMIKV8gHotVb8Ejnx9UQuz0JOlJMmxC0
Message-ID: <CAHk-=wgfWG+MHXoFG2guu2GAoSBrmcdXU2apj+MJpgdCXxwbwA@mail.gmail.com>
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for 6.17-rc5)
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Jens Axboe <axboe@kernel.dk>, Konstantin Ryabitsev <konstantin@linuxfoundation.org>, 
	Jakub Kicinski <kuba@kernel.org>, "Rafael J. Wysocki" <rafael@kernel.org>, dan.j.williams@intel.com, 
	Caleb Sander Mateos <csander@purestorage.com>, io-uring <io-uring@vger.kernel.org>, 
	workflows@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"

On Tue, 9 Sept 2025 at 11:07, Vlastimil Babka <vbabka@suse.cz> wrote:
>
> Later in the thread patch-id is mentioned. I think it was mentioned in the
> past threads that due to small context changes due to e.g. base that the
> submitter used and the maintainer used to apply, and even diff algorithm not
> being set in stone, they can't be made fully reliable?

Yes, the patch-id is a heuristic. It's really a very good heuristic in
practice, though.

Also, if the argument is "it might not always work", I still claim
that "99.5% useful" is a hell of a lot better than "_maybe_ useful in
the future, but known to be painful".

Because that's the trade-off here: people are arguing for something
that wastes time and effort, and with very dubious use cases.

But yes: please do continue to add links to the original email - IF
you thought about it. That has always been my standpoint. Exactly like
"Fixes", and exactly like EVERY SINGLE OTHER THING you add to a commit
message.

              Linus

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id E08FC78F3E
	for <io-uring@vger.kernel.org>; Tue,  9 Sep 2025 18:22:07 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.135.223.131
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757442129; cv=none; b=ZR6h9yYCJsxowpnIDgYVbr5Vuuy7rcx4wtg1C9YIgh3cehOzzJtdqkowRvk81Scra0XmWhlfFtXIq2ou1V0A8qeVxPuZKpqxoVAT77cy1XfoZCc1q2sCL+GSOwb/8ioFhW9E+MIZ/v+pMK+bZt204biPZ/QugidMk+YizquSnxs=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757442129; c=relaxed/simple;
	bh=hXp/ZyWum48qrW+rr93lUTCjt3zAmbOIedkySaeC2Ew=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=u0qlOKpVzZHBKumnwQOUV94myWFFakRzGrTaDpT/rykBhvhupqQiti+Dl5r8K2NkSJpCsexe46yfxUQJA385SwdH9DvNm8xTlx9ZAOBtuiRItINlXTYb4cTnafiyJP7xdKuzgksPhtbBBSABsfkpz3mgaF89bT6tgoFYdM42AeU=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz; spf=pass smtp.mailfrom=suse.cz; dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b=pJhWgwG8; dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b=L/0bAa4S; dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b=rTd5a7oP; dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b=hhaBbFzQ; arc=none smtp.client-ip=195.135.223.131
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.cz
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b="pJhWgwG8";
	dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b="L/0bAa4S";
	dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b="rTd5a7oP";
	dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b="hhaBbFzQ"
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(No client certificate requested)
	by smtp-out2.suse.de (Postfix) with ESMTPS id E44CE20E1A;
	Tue,  9 Sep 2025 18:22:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa;
	t=1757442126; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=n3X/bhSH1V6b9Cq21vMkSAOYlwaOTnjm2pW4VrBb10o=;
	b=pJhWgwG8HvEJTHDn0mfFkncKYaNmv7kCBDIjt3rsIArQJnPiOUe5kFPHqWSbtiC0sQp2Rc
	LgHw9mvoxAKJ7vrgazVZkVSaDVVi4+hUGTHfPh1p7oniApN7j2qvPYD0+wcAQ++C9IfO84
	a203ppH8u8iAOsRnA3vOVO20QwkvhlM=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz;
	s=susede2_ed25519; t=1757442126;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=n3X/bhSH1V6b9Cq21vMkSAOYlwaOTnjm2pW4VrBb10o=;
	b=L/0bAa4SrtWYNvWtT5F3j+HeGQQ8d7QKBRHnIMagP1BPJ/2Rj0yJ89BNAFK1nKRd5TLUok
	YXxXvLMNbBlT+FBQ==
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa;
	t=1757442125; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=n3X/bhSH1V6b9Cq21vMkSAOYlwaOTnjm2pW4VrBb10o=;
	b=rTd5a7oPVEcu6jIA2FAH0yprdHAxqRLCigHAM2Y9HSCyrg7JZpzB86NHeA7cslbH4qtJ+v
	g9+XCQ3gIZxW3fcflFVgugXJPbs0ILr9acju0nPIczRRnYniZ2fDE4SFW0uzW7DJFsNXUi
	8c8TyEGktTiNc8fD6Kzom1jrAuz289c=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz;
	s=susede2_ed25519; t=1757442125;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=n3X/bhSH1V6b9Cq21vMkSAOYlwaOTnjm2pW4VrBb10o=;
	b=hhaBbFzQZGR9o9wDRdSfLCHIvPbe7eTYclzeSze/zFYH+17cK6HHgxtoXz8sly8anSjf5y
	zKx9CNHVI7OViHDw==
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(No client certificate requested)
	by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id C77141388C;
	Tue,  9 Sep 2025 18:22:05 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
	by imap1.dmz-prg2.suse.org with ESMTPSA
	id xcsYME1wwGifOQAAD6G6ig
	(envelope-from <vbabka@suse.cz>); Tue, 09 Sep 2025 18:22:05 +0000
Message-ID: <ad587c82-cc9c-43ef-89c5-d208734a4c7f@suse.cz>
Date: Tue, 9 Sep 2025 20:22:05 +0200
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
Content-Language: en-US
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jens Axboe <axboe@kernel.dk>,
 Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
 Jakub Kicinski <kuba@kernel.org>, "Rafael J. Wysocki" <rafael@kernel.org>,
 dan.j.williams@intel.com, Caleb Sander Mateos <csander@purestorage.com>,
 io-uring <io-uring@vger.kernel.org>, workflows@vger.kernel.org
References: <9ef87524-d15c-4b2c-9f86-00417dad9c48@kernel.dk>
 <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <68bf3854f101b_4224d100d7@dwillia2-mobl4.notmuch>
 <5922560.DvuYhMxLoT@rafael.j.wysocki> <20250909071818.15507ee6@kernel.org>
 <92dc8570-84a2-4015-9c7a-6e7da784869a@kernel.dk>
 <20250909-green-oriole-of-speed-85cd6d@lemur>
 <497c9c10-3309-49b9-8d4f-ff0bc34df4e5@suse.cz>
 <be98399d-3886-496e-9cf4-5ec909124418@kernel.dk>
 <CAHk-=whP2zoFm+-EmgQ69-00cxM5jgoEGWyAYVQ8bQYFbb2j=Q@mail.gmail.com>
 <e09555bc-4b0f-4f3a-82a3-914f38c3cde5@suse.cz>
 <CAHk-=wgfWG+MHXoFG2guu2GAoSBrmcdXU2apj+MJpgdCXxwbwA@mail.gmail.com>
From: Vlastimil Babka <vbabka@suse.cz>
Autocrypt: addr=vbabka@suse.cz; keydata=
 xsFNBFZdmxYBEADsw/SiUSjB0dM+vSh95UkgcHjzEVBlby/Fg+g42O7LAEkCYXi/vvq31JTB
 KxRWDHX0R2tgpFDXHnzZcQywawu8eSq0LxzxFNYMvtB7sV1pxYwej2qx9B75qW2plBs+7+YB
 87tMFA+u+L4Z5xAzIimfLD5EKC56kJ1CsXlM8S/LHcmdD9Ctkn3trYDNnat0eoAcfPIP2OZ+
 9oe9IF/R28zmh0ifLXyJQQz5ofdj4bPf8ecEW0rhcqHfTD8k4yK0xxt3xW+6Exqp9n9bydiy
 tcSAw/TahjW6yrA+6JhSBv1v2tIm+itQc073zjSX8OFL51qQVzRFr7H2UQG33lw2QrvHRXqD
 Ot7ViKam7v0Ho9wEWiQOOZlHItOOXFphWb2yq3nzrKe45oWoSgkxKb97MVsQ+q2SYjJRBBH4
 8qKhphADYxkIP6yut/eaj9ImvRUZZRi0DTc8xfnvHGTjKbJzC2xpFcY0DQbZzuwsIZ8OPJCc
 LM4S7mT25NE5kUTG/TKQCk922vRdGVMoLA7dIQrgXnRXtyT61sg8PG4wcfOnuWf8577aXP1x
 6mzw3/jh3F+oSBHb/GcLC7mvWreJifUL2gEdssGfXhGWBo6zLS3qhgtwjay0Jl+kza1lo+Cv
 BB2T79D4WGdDuVa4eOrQ02TxqGN7G0Biz5ZLRSFzQSQwLn8fbwARAQABzSBWbGFzdGltaWwg
 QmFia2EgPHZiYWJrYUBzdXNlLmN6PsLBlAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIe
 AQIXgBYhBKlA1DSZLC6OmRA9UCJPp+fMgqZkBQJnyBr8BQka0IFQAAoJECJPp+fMgqZkqmMQ
 AIbGN95ptUMUvo6aAdhxaOCHXp1DfIBuIOK/zpx8ylY4pOwu3GRe4dQ8u4XS9gaZ96Gj4bC+
 jwWcSmn+TjtKW3rH1dRKopvC07tSJIGGVyw7ieV/5cbFffA8NL0ILowzVg8w1ipnz1VTkWDr
 2zcfslxJsJ6vhXw5/npcY0ldeC1E8f6UUoa4eyoskd70vO0wOAoGd02ZkJoox3F5ODM0kjHu
 Y97VLOa3GG66lh+ZEelVZEujHfKceCw9G3PMvEzyLFbXvSOigZQMdKzQ8D/OChwqig8wFBmV
 QCPS4yDdmZP3oeDHRjJ9jvMUKoYODiNKsl2F+xXwyRM2qoKRqFlhCn4usVd1+wmv9iLV8nPs
 2Db1ZIa49fJet3Sk3PN4bV1rAPuWvtbuTBN39Q/6MgkLTYHb84HyFKw14Rqe5YorrBLbF3rl
 M51Dpf6Egu1yTJDHCTEwePWug4XI11FT8lK0LNnHNpbhTCYRjX73iWOnFraJNcURld1jL1nV
 r/LRD+/e2gNtSTPK0Qkon6HcOBZnxRoqtazTU6YQRmGlT0v+rukj/cn5sToYibWLn+RoV1CE
 Qj6tApOiHBkpEsCzHGu+iDQ1WT0Idtdynst738f/uCeCMkdRu4WMZjteQaqvARFwCy3P/jpK
 uvzMtves5HvZw33ZwOtMCgbpce00DaET4y/UzsBNBFsZNTUBCACfQfpSsWJZyi+SHoRdVyX5
 J6rI7okc4+b571a7RXD5UhS9dlVRVVAtrU9ANSLqPTQKGVxHrqD39XSw8hxK61pw8p90pg4G
 /N3iuWEvyt+t0SxDDkClnGsDyRhlUyEWYFEoBrrCizbmahOUwqkJbNMfzj5Y7n7OIJOxNRkB
 IBOjPdF26dMP69BwePQao1M8Acrrex9sAHYjQGyVmReRjVEtv9iG4DoTsnIR3amKVk6si4Ea
 X/mrapJqSCcBUVYUFH8M7bsm4CSxier5ofy8jTEa/CfvkqpKThTMCQPNZKY7hke5qEq1CBk2
 wxhX48ZrJEFf1v3NuV3OimgsF2odzieNABEBAAHCwXwEGAEKACYCGwwWIQSpQNQ0mSwujpkQ
 PVAiT6fnzIKmZAUCZ8gcVAUJFhTonwAKCRAiT6fnzIKmZLY8D/9uo3Ut9yi2YCuASWxr7QQZ
 lJCViArjymbxYB5NdOeC50/0gnhK4pgdHlE2MdwF6o34x7TPFGpjNFvycZqccSQPJ/gibwNA
 zx3q9vJT4Vw+YbiyS53iSBLXMweeVV1Jd9IjAoL+EqB0cbxoFXvnjkvP1foiiF5r73jCd4PR
 rD+GoX5BZ7AZmFYmuJYBm28STM2NA6LhT0X+2su16f/HtummENKcMwom0hNu3MBNPUOrujtW
 khQrWcJNAAsy4yMoJ2Lw51T/5X5Hc7jQ9da9fyqu+phqlVtn70qpPvgWy4HRhr25fCAEXZDp
 xG4RNmTm+pqorHOqhBkI7wA7P/nyPo7ZEc3L+ZkQ37u0nlOyrjbNUniPGxPxv1imVq8IyycG
 AN5FaFxtiELK22gvudghLJaDiRBhn8/AhXc642/Z/yIpizE2xG4KU4AXzb6C+o7LX/WmmsWP
 Ly6jamSg6tvrdo4/e87lUedEqCtrp2o1xpn5zongf6cQkaLZKQcBQnPmgHO5OG8+50u88D9I
 rywqgzTUhHFKKF6/9L/lYtrNcHU8Z6Y4Ju/MLUiNYkmtrGIMnkjKCiRqlRrZE/v5YFHbayRD
 dJKXobXTtCBYpLJM4ZYRpGZXne/FAtWNe4KbNJJqxMvrTOrnIatPj8NhBVI0RSJRsbilh6TE
 m6M14QORSWTLRg==
In-Reply-To: <CAHk-=wgfWG+MHXoFG2guu2GAoSBrmcdXU2apj+MJpgdCXxwbwA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Level: 
X-Spamd-Result: default: False [-4.30 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.20)[-0.997];
	MIME_GOOD(-0.10)[text/plain];
	FUZZY_RATELIMITED(0.00)[rspamd.com];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[9];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	DKIM_SIGNED(0.00)[suse.cz:s=susede2_rsa,suse.cz:s=susede2_ed25519];
	FROM_HAS_DN(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_DN_SOME(0.00)[]
X-Spam-Flag: NO
X-Spam-Score: -4.30

On 9/9/25 20:14, Linus Torvalds wrote:
> On Tue, 9 Sept 2025 at 11:07, Vlastimil Babka <vbabka@suse.cz> wrote:
>>
>> Later in the thread patch-id is mentioned. I think it was mentioned in the
>> past threads that due to small context changes due to e.g. base that the
>> submitter used and the maintainer used to apply, and even diff algorithm not
>> being set in stone, they can't be made fully reliable?
> 
> Yes, the patch-id is a heuristic. It's really a very good heuristic in
> practice, though.
> 
> Also, if the argument is "it might not always work", I still claim
> that "99.5% useful" is a hell of a lot better than "_maybe_ useful in
> the future, but known to be painful".
> 
> Because that's the trade-off here: people are arguing for something
> that wastes time and effort, and with very dubious use cases.
> 
> But yes: please do continue to add links to the original email - IF
> you thought about it. That has always been my standpoint. Exactly like
> "Fixes", and exactly like EVERY SINGLE OTHER THING you add to a commit
> message.

Fine, maybe b4 could help here by verifying if patch-id works on commits in
the maintainer's branch before sending a pr, and for those where it doesn't,
the maintainer can decide to add them. It sounds more useful to me than
adding anything "AI-powered" to it.

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 272CA369325;
	Tue,  9 Sep 2025 18:31:15 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757442676; cv=none; b=EoYmIKY9EmpztzZw6NdB+LZrkStB2rdtPDM3EFRCHolpdYIxe3IvMVi5ZCwlh3fByczCAgEPjJPi5UWo2nHBXwf6xozb9bnoVBSejxyStU41dehcmRlS+FecMFfbNBD+dhnNnFD5bb03lCqqq49luaBMKDDfn81kWsKciZcABR4=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757442676; c=relaxed/simple;
	bh=U+8cGGxdMKAK3+g3uYEoGNshqNn7XrOcxEGGs2HE1cw=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=V9+hKQyYDGjXqBMt0eP8/M+4+YxCMDGsMfhSohUvg2tER9tOag2JQmp471RcuapuY6cNyfez1+7vo22YXTKZcIKVjNT54kAWbqP3cL8G422aanb/OiHP83kbaWX/iWKUVCgu8liTjqHgbGBhZHC8Mxf+x+QJL/9FTSh4hKWCS9I=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=m7S5fUZL; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="m7S5fUZL"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7ED57C4CEF4;
	Tue,  9 Sep 2025 18:31:15 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1757442675;
	bh=U+8cGGxdMKAK3+g3uYEoGNshqNn7XrOcxEGGs2HE1cw=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=m7S5fUZLM0FsgbT3hmz7xiWKG6R4+wzDFYKJB6mafLSRvSz0EGfGU+N0cFtBICuOG
	 6Xxq48GEIoCLKl1j5+yzHKrviCK746OmAd4Kxl8AG2EBtSpckupuGpLMyl/0YhiINt
	 v3i2C4uFBtsVACspNeuIpFb0tXlJEzZUPVFba+A4=
Date: Tue, 9 Sep 2025 14:31:14 -0400
From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mark Brown <broonie@kernel.org>, Jens Axboe <axboe@kernel.dk>, 
	Vlastimil Babka <vbabka@suse.cz>, Jakub Kicinski <kuba@kernel.org>, 
	"Rafael J. Wysocki" <rafael@kernel.org>, dan.j.williams@intel.com, 
	Caleb Sander Mateos <csander@purestorage.com>, io-uring <io-uring@vger.kernel.org>, workflows@vger.kernel.org
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
Message-ID: <20250909-impetuous-swine-of-chaos-2aa9af@meerkat>
References: <5922560.DvuYhMxLoT@rafael.j.wysocki>
 <20250909071818.15507ee6@kernel.org>
 <92dc8570-84a2-4015-9c7a-6e7da784869a@kernel.dk>
 <20250909-green-oriole-of-speed-85cd6d@lemur>
 <497c9c10-3309-49b9-8d4f-ff0bc34df4e5@suse.cz>
 <be98399d-3886-496e-9cf4-5ec909124418@kernel.dk>
 <CAHk-=whP2zoFm+-EmgQ69-00cxM5jgoEGWyAYVQ8bQYFbb2j=Q@mail.gmail.com>
 <af29e72b-ade6-4549-b264-af31a3128cf1@sirena.org.uk>
 <CAHk-=wiN+8EUoik4UeAJ-HPSU7hczQP+8+_uP3vtAy_=YfJ9PQ@mail.gmail.com>
 <CAHk-=wh2F5EPJWhiEeW=Ft0rx9HFcZj2cWnNGh_OuR0kdBm8UA@mail.gmail.com>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAHk-=wh2F5EPJWhiEeW=Ft0rx9HFcZj2cWnNGh_OuR0kdBm8UA@mail.gmail.com>

On Tue, Sep 09, 2025 at 10:58:53AM -0700, Linus Torvalds wrote:
> On Tue, 9 Sept 2025 at 10:50, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> >    patchid=$(git diff-tree -p fef7ded169ed7e133612f90a032dc2af1ce19bef
> > | git patch-id | cut -d' ' -f1)
> 
> Oh, and looking more at that, use Dan's version instead.  You almost
> certainly want to use '--stable' like Dan did, although maybe
> Konstantin can speak up on what option lore actually uses for
> indexing.

It uses --stable.

> And you *can* screw up patchid matching. In particular, you can
> generate patches different ways, and patch-id won't generate the same
> thing for a rename patch and a add/delete patch, for example (again:
> the traditional use case is that you generate the patch IDs all from
> the same tree, so you control how you generate the patches)

We can't control how the patches are generated by submitters. If someone
generates and sends them with --histogram, this won't work. Here's an example
right from your tree:

    $ git show 1c67f9c54cdc70627e3f6472b89cd3d895df974c | git patch-id --stable | cut -d' ' -f1
    57cb8d951fd1006d885f6bc7083283d3bc6040c1

    $ git show --histogram 1c67f9c54cdc70627e3f6472b89cd3d895df974c | git patch-id --stable | cut -d' ' -f1
    47b4bfff33d1456d0a2bb30f8bd74e1cfe9eb31e

Or if someone generates with -U5 instead of the default (-U3):

    $ git show 1c67f9c54cdc70627e3f6472b89cd3d895df974c -U5 | git patch-id --stable | cut -d' ' -f1
    0b68dd472dc791447c3091f7a671e7f1e5d7a3d2

This is more than just annoying -- this can be misleading and confusing. If
the submitter sent v1, v2, v3 with the default parameters and then sent v4
with --histogram, then you may think v3 was the final version that got applied
and it will waste a lot of your time trying to figure out why it doesn't match
what's in the tree.

I don't have precise statistics, but I do have firsthand experience trying to
make this work with git-patch-id, because this is how git-patchwork-bot works,
and we can't match a significant portion of commits to patches.

-K

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 DC291301000;
	Tue,  9 Sep 2025 18:54:56 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757444097; cv=none; b=HW0uOASmyHHoOL0+V5Hf/LDhJTevafh1TEUUps8/8SxGz8Nv6rHqCWYT+KuIfvjtTEPZsXnORMKWKeNDpVaOy3r7vNrFgvd2A0aHPgZVZClvciQx9A5woNnuVM7lR5wZAq5DO1pBY8JA7HwZ933uUVqe9S/SYfG8eq9GtseIO28=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757444097; c=relaxed/simple;
	bh=jY4ZDiOqfedwHS40fQ7APUViCr1cLuPVU29y7/rD8dM=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=cEwDesi0vJi9LX3oFWYPXF2f6RYE+nImEKOLOHhyQBGc21yEl9IP3Se0T2rHQAO/CQrreuU6udoTb6LUxmV9Dfehwao2tZeQcRzJ6M+GoM/DhWnIp8LlnsvUKConJq3iAfE4ZglV8KlJ6T10qG/ZPL3tNlcGLMobPThmu4uke1w=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QBmAoIP2; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QBmAoIP2"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3E86AC4CEF4;
	Tue,  9 Sep 2025 18:54:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757444096;
	bh=jY4ZDiOqfedwHS40fQ7APUViCr1cLuPVU29y7/rD8dM=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=QBmAoIP25QwBASgbLBhCAHpGzGwWCwKhwHDX9iyEh4YOQE2iVo7duqLaHhx8COplO
	 3rczqoEg6pNcdQUWd9fOA4U09/Nyt3ZCnWmAKTjyGWn4cPd8jup+1yh0puvWPj4+IG
	 iNVbloCMZQdPjEQP/9c3309bZD9o2byoKZY3Qbf0NVD66KsIj7njM97s8S4sbEDFQQ
	 F2+7OhXmdLAHd4PxLi9T/CIK2GYXnRBPT6y7HSyrxJ7TALfxZZkPS11MK1b29SACys
	 OOvNKREkZ/B4lK6cPQTfz5KDh/l2sFQdGOjW8Ei6sIR/C3vfVP+q7IEqztWZwxBwqJ
	 6I9uSdcmgqKxA==
Date: Tue, 9 Sep 2025 14:54:53 -0400
From: Sasha Levin <sashal@kernel.org>
To: Jens Axboe <axboe@kernel.dk>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	konstantin@linuxfoundation.org, csander@purestorage.com,
	io-uring@vger.kernel.org, torvalds@linux-foundation.org,
	workflows@vger.kernel.org
Subject: Re: [RFC] b4 dig: Add AI-powered email relationship discovery command
Message-ID: <aMB3_VgB4mwp-bzP@laps>
References: <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <20250909163214.3241191-1-sashal@kernel.org>
 <20250909172258.GH18349@pendragon.ideasonboard.com>
 <72dd17ad-5467-49d3-9f40-054b1bf875d5@kernel.dk>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <72dd17ad-5467-49d3-9f40-054b1bf875d5@kernel.dk>

On Tue, Sep 09, 2025 at 11:26:19AM -0600, Jens Axboe wrote:
>On 9/9/25 11:22 AM, Laurent Pinchart wrote:
>> On Tue, Sep 09, 2025 at 12:32:14PM -0400, Sasha Levin wrote:
>>> Add a new 'b4 dig' subcommand that uses AI agents to discover related
>>> emails for a given message ID. This helps developers find all relevant
>>> context around patches including previous versions, bug reports, reviews,
>>> and related discussions.
>>
>> That really sounds like "if all you have is a hammer, everything looks
>> like a nail". The community has been working for multiple years to
>> improve discovery of relationships between patches and commits, with
>> great tools such are lore, lei and b4, and usage of commit IDs, patch
>> IDs and message IDs to link everything together. Those provide exact
>> results in a deterministic way, and consume a fraction of power of what
>> this patch would do. It would be very sad if this would be the direction
>> we decide to take.
>
>Fully agree, this kind of lazy "oh just waste billions of cycles and
>punt to some AI" bs is just kind of giving up on proper infrastructure
>to support maintainers and developers.

This feels like a false choice: why force a pick between b4-dig-like tooling
and improving our infra? They can work together. As tagging and workflows
improve, those gains will flow into the tools anyway.

It's like saying we should skip -rc releases because they mean we've given up
on bug free code.

Perfect is the enemy of the good. You're arguing against a tool that works now,
just because it's not ideal, and to chase perfection instead. I'd rather be
"lazy" and skip the endless lore hunts.

-- 
Thanks,
Sasha

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13])
	(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 E0D1C238D3A;
	Tue,  9 Sep 2025 19:36:21 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=192.198.163.13
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757446583; cv=fail; b=U3EFzn3njj4uotXTCFkKbKHXPZcpFxXWwUzYrnSyqzpluz+KleO8xSOlOTXikni8YoS+lr6PRF5f6QDC/XxK5fT6v2PMvfb/cd43rkOAKrO9Z9Lu/9CmmSTRG65/VcC2zhN6oeouiyGQpbEV8hNPnKkcwtU586dGavP+QQrKRK0=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757446583; c=relaxed/simple;
	bh=Y/8rPp+U0q1tZqwPrHSggbNLVdWKhMmdbOATkZzfipI=;
	h=From:Date:To:CC:Message-ID:In-Reply-To:References:Subject:
	 Content-Type:MIME-Version; b=jPE/xueVF+IBfGd29+AtUY1i48kcILlWZYJCrNRMIKtUkdh0uZIQykXq40dfUJ99CNwFi0tJflW8LVWNY213FT7Rknb5Qn3w9nF9SHNDr3fl74fM1IYg6xIPV+sngpXayv89V77gFYYpiOqLR4C5spWcPVfENKFcqN03Cf1lIkw=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=PryngjAe; arc=fail smtp.client-ip=192.198.163.13
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="PryngjAe"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1757446582; x=1788982582;
  h=from:date:to:cc:message-id:in-reply-to:references:
   subject:content-transfer-encoding:mime-version;
  bh=Y/8rPp+U0q1tZqwPrHSggbNLVdWKhMmdbOATkZzfipI=;
  b=PryngjAeMRmmF6jaCvwnG8Zk/pPe10Gm6HmfnoXCNYtBVhbzwE4VBolA
   22thI927S++2dyBZgEgPQ651T5J+q1Xx1L5ZG/HDQH+NrI9bEopo5HNrY
   VQIOiu3Meh114jmT1pcRtE/aueQUrWpoKrlWXI3+6VAkeVgy9nH3j+d1V
   B53Uf0Ps4xvDGnhhauj95yT1cYFuQ/VFaknj+uOnp+En95gNJ2yyAcVtL
   aKpPA8QxPvJPip5pt4gIXT7MaoKC0Ng9qkbG8p+cnWOQPibjO3VwXkwhH
   /gkgIXTLfIbtPjdij7ibMSokYtip5mUzHpbdrnPA+34Md1i4FCqsXUMdD
   A==;
X-CSE-ConnectionGUID: 9cewAbo9TI2s3mIbgpgJUw==
X-CSE-MsgGUID: UZg9z7pDRf6nXDN6EbCGMw==
X-IronPort-AV: E=McAfee;i="6800,10657,11548"; a="62375477"
X-IronPort-AV: E=Sophos;i="6.18,252,1751266800"; 
   d="scan'208";a="62375477"
Received: from fmviesa001.fm.intel.com ([10.60.135.141])
  by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2025 12:36:20 -0700
X-CSE-ConnectionGUID: WcQzhxBuQ9+9eRm5i+c3dQ==
X-CSE-MsgGUID: fr/lFy1vRtKNlA7iAWikLw==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.18,252,1751266800"; 
   d="scan'208";a="204164723"
Received: from orsmsx902.amr.corp.intel.com ([10.22.229.24])
  by fmviesa001.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2025 12:36:20 -0700
Received: from ORSMSX901.amr.corp.intel.com (10.22.229.23) by
 ORSMSX902.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Tue, 9 Sep 2025 12:36:19 -0700
Received: from ORSEDG901.ED.cps.intel.com (10.7.248.11) by
 ORSMSX901.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17 via Frontend Transport; Tue, 9 Sep 2025 12:36:19 -0700
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (40.107.92.72) by
 edgegateway.intel.com (134.134.137.111) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Tue, 9 Sep 2025 12:36:19 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=exNFoQvYRr+KoG6oQkdUoYKolLzHzyuJ4MIPJgaWKFTgnCjGT1ttSNgpSobPk6Vs6crHlVgSTjje94nVBh3jJLI3js7eNlyjUwQAFYGtVhiJAvTqJBCT++sj3nw4k4gbuQLB2XF3wtaHDuF9SjlWydM7DRgmA/ROi0l3TuI7sWnxQUSMjzw1Fmp8LSkJCP3bruYcJjq5xo6BGjcpLUNFNRRSCU6eaLve4LIeokqi1s+psjNMF45D+gFgM8Z35mQuLxeKWgiFx0/SxkAJcMbna/uOCd1Ji8EoggUXUESCDnMZRgdLrNfqutTHPmxQmXI6HEkWiU/aaRkLCEPN7gbKYw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=dvm4xnJG4jwOoVrfVnOHS1+14hmjWvooEzAn6dF18is=;
 b=uHyAddTmjB4IaQiY/v5aEG2Q3PmrJVCR4RaUa5Y9MvZqYwHQH0vqiQDDxK4uLBE6UUrbhD5h13rLM1J/FQslOf6ZHOE9uNTqt+kd3i533Ioc/fB1VhUdDaYCCRElpK4u040QcxJkwoaUp/Hx/IBVQeWC+tJXih34dViVW3IUpPsyMvJ3qwonhj2qT0CDzDcqej9Vy2iVmKLKpGU1f9N4J1QVR9MJ5eXvBvnXQrPoiZuxjC8hewov2usPfdjjFTCFJTerVW9Nbd2FQdTehfeSGPdA8TvCxXLLb3sIzQV6dc3oojsl6IBX4UKCNCTc/0N2ujB2F1gJaPkRQ/Izmqy/HA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;
 dkim=pass header.d=intel.com; arc=none
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=intel.com;
Received: from PH8PR11MB8107.namprd11.prod.outlook.com (2603:10b6:510:256::6)
 by SA1PR11MB7700.namprd11.prod.outlook.com (2603:10b6:806:330::17) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Tue, 9 Sep
 2025 19:36:17 +0000
Received: from PH8PR11MB8107.namprd11.prod.outlook.com
 ([fe80::6b05:74cf:a304:ecd8]) by PH8PR11MB8107.namprd11.prod.outlook.com
 ([fe80::6b05:74cf:a304:ecd8%2]) with mapi id 15.20.9094.021; Tue, 9 Sep 2025
 19:36:17 +0000
From: <dan.j.williams@intel.com>
Date: Tue, 9 Sep 2025 12:36:16 -0700
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>, Linus Torvalds
	<torvalds@linux-foundation.org>
CC: Mark Brown <broonie@kernel.org>, Jens Axboe <axboe@kernel.dk>, "Vlastimil
 Babka" <vbabka@suse.cz>, Jakub Kicinski <kuba@kernel.org>, "Rafael J.
 Wysocki" <rafael@kernel.org>, <dan.j.williams@intel.com>, Caleb Sander Mateos
	<csander@purestorage.com>, io-uring <io-uring@vger.kernel.org>,
	<workflows@vger.kernel.org>
Message-ID: <68c081b0c010c_4224d10077@dwillia2-mobl4.notmuch>
In-Reply-To: <20250909-impetuous-swine-of-chaos-2aa9af@meerkat>
References: <5922560.DvuYhMxLoT@rafael.j.wysocki>
 <20250909071818.15507ee6@kernel.org>
 <92dc8570-84a2-4015-9c7a-6e7da784869a@kernel.dk>
 <20250909-green-oriole-of-speed-85cd6d@lemur>
 <497c9c10-3309-49b9-8d4f-ff0bc34df4e5@suse.cz>
 <be98399d-3886-496e-9cf4-5ec909124418@kernel.dk>
 <CAHk-=whP2zoFm+-EmgQ69-00cxM5jgoEGWyAYVQ8bQYFbb2j=Q@mail.gmail.com>
 <af29e72b-ade6-4549-b264-af31a3128cf1@sirena.org.uk>
 <CAHk-=wiN+8EUoik4UeAJ-HPSU7hczQP+8+_uP3vtAy_=YfJ9PQ@mail.gmail.com>
 <CAHk-=wh2F5EPJWhiEeW=Ft0rx9HFcZj2cWnNGh_OuR0kdBm8UA@mail.gmail.com>
 <20250909-impetuous-swine-of-chaos-2aa9af@meerkat>
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: SJ0PR13CA0232.namprd13.prod.outlook.com
 (2603:10b6:a03:2c1::27) To PH8PR11MB8107.namprd11.prod.outlook.com
 (2603:10b6:510:256::6)
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR11MB8107:EE_|SA1PR11MB7700:EE_
X-MS-Office365-Filtering-Correlation-Id: 68cd5258-410d-461b-be05-08ddefd8255a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|7416014;
X-Microsoft-Antispam-Message-Info: =?utf-8?B?MVpDakQ3bUxxT1E0d1VWYjU5dmd6WTR4Mk5VZU9wQzkwbFBEakRyc0F0NUQy?=
 =?utf-8?B?RWFGampuelg4dVQvMzhBajhBRGJjem9tRzZvUEtKQ0Q2T3Z3N2pRUWpoNWxy?=
 =?utf-8?B?ZTRidm1XZEp5eUp2MVJCQlhIYjlUc1p5RE9FWmRlWXhwZTJqeThKSm13c0dK?=
 =?utf-8?B?S1h4cjZQYzhqOGpkcVRLYXVobWRhUFB3TEY1c3VNbkYvRmFGenlvMStvcGVp?=
 =?utf-8?B?QVdZQkhMRDg4cVdONTMxeDVveTFoVkwwWEtTa1oyVVVUbHhQK0I1UGtETDRY?=
 =?utf-8?B?U3pDYk5RVkJJRlhXVlB2ZFlIZDF6eEdrbEU4OW1oUlJjRVZwZ0NhUkNYcXdS?=
 =?utf-8?B?OEVzMUE5OFRVM0VRQmZKZ0VqOWxFV0VSKzlSNjBvTTdUZUdpclFuQWpYK2pH?=
 =?utf-8?B?dTBOMUhKcUJDK2d1Y2x6a0wwL1ZaeUNZOW9VZnB2eXVLK1ZKS2JSb252V2do?=
 =?utf-8?B?bXV1bXBrc0l3ZzFabXAyQ28va1NDWlNsSVVqeWd4SDgxZkg5RTBGV2pGYllS?=
 =?utf-8?B?K2VIekN0VWVMWkNUdmhEUE14VjcwLzBFVlBlSXJTdlJCN2FzVndRMU8vdXpw?=
 =?utf-8?B?OGtEVDlmU1Z5ZmlyL2dSc3VuUnNtcUxzNnpEb25maVRmK2tkL3NLWXdOZnJz?=
 =?utf-8?B?V3VxNjY1YnpYR0dhaXFRdnpWRFNPL2VYTzdrTEJnR2l6TGdETkJaWXMyeW5Z?=
 =?utf-8?B?NTRBMndvUzRabEdUZm5CZlF5N0Rpelo1bXF6b3V5OTJlYm1sTHI4ZVdESnlR?=
 =?utf-8?B?NllkQzlqYjZaTnBHR0hwNDlGaURpaU1CYTlKSTl0M2FMT1NCeklLM0ZNdDN0?=
 =?utf-8?B?SW4zVWpDWVpRR3lGczIvckdsV09jUGMwWlpBVmdma2s0Z21odXo5WUdJTlB0?=
 =?utf-8?B?bzBpTEpKT0FCMHlseHJCc3dVN0gwWk42WjlQVnRvcUNzWUplWldBUHZTVEdx?=
 =?utf-8?B?YXRhRTNWOFZaWUV6TjlycVJZbFhBZ05tOFdXMzhXeWovajBGYWlWRFRSWElB?=
 =?utf-8?B?SHFYUEtJYXZ6SUwxTGNQRU5ZUCtBemNrZ1B1cis1UjNJZTQvVmQ1SmdoZ2x3?=
 =?utf-8?B?TkxyQ2VlTUFUV1VKczJ2SFhFcEhKdWExNWJZMnlPOHJMNXRHODdzNXE4MHIz?=
 =?utf-8?B?aUZlVG5DRWRTbkcxTGlMZ0ZnQ3Exam11Z2FwcTQzSUowTlRaRThIR0dPWURx?=
 =?utf-8?B?VEtFd200NTdLOXErZmxGU2g0ZzJ5TUhzTzF1UmZBamVXNGEwQ0NqOHVHaUJR?=
 =?utf-8?B?b2dzcGp2aFkzd2szcnpsTXBxZ01oS1VQSGVtOU5JUjIvUzJtOFM3dVcxc3J1?=
 =?utf-8?B?a2pLMjlPbmRZVVBUbWQvK2NGK25vdHdNOWd3cThERzBPVGh2ZXdRcDlMdEtJ?=
 =?utf-8?B?NXZ5U2ZCTllrKzd3ZmR5RjRqRDRGUkpnWmRrWW14YkU1Tjd3QlN1R01sSkZ2?=
 =?utf-8?B?WnlKYk9aSmdhRnJBT2lXU1ZpeUFqSEEra3pIZ21nNXpnRkNNNEJkejIxRE0w?=
 =?utf-8?B?N2FPWTRsVWx2clhYMXNCQVJWek5MKzlwU2JOMm0xcTZleFd5dEplS3pCSVBi?=
 =?utf-8?B?UWdNZGdFcTZudFpwZ2pkTWFrdWg5S3AzWlkwN0k0cHRIdzhWRG5qYTJERk9C?=
 =?utf-8?B?NWlpMVhaQVBHRHVZNUVmcWVrVUNBVWt5dGtkUTRWdjFJQjVLU0JwZVRTaUdR?=
 =?utf-8?B?R01tc25aS2tRZmpjREN3aGdUMVJQbGRGZktnbmlhRWFiMTJwVGwyYUpzd2dM?=
 =?utf-8?B?MFo4ekl4MHdzZk5VNjN2VWdob2xYQ2p6M0VBcGVrTzJyN2hkY2ZuZzVMMnhu?=
 =?utf-8?B?TEM4aHBPS3N2VEovSVBQUVZhVGVMaVAvZDQzcmU0NGg3RzV2b3BOYVVmRDBz?=
 =?utf-8?B?ZDZNRzlTSmNlekxKRWZ4ODI5cEVOYXg2ODJkZ0xrZEswbDloWklmNGlIZnRa?=
 =?utf-8?Q?dTPhm+sMPOo=3D?=
X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH8PR11MB8107.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(7416014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Qkh1MStsY0ExdUtzVHZWNEUwQmRUelBxK1BGOEV6akhIQnkwbWpxRkRPeFU4?=
 =?utf-8?B?UzJnSExKNjhjZG8rUU1nelFYeTh0TmovUGdqOXVMb0NHM0hXVHlVd2RROUcz?=
 =?utf-8?B?WEZjYi80WXRUbkR3bVNveFVWM01kVHZsN2g4YlE4ZVY4cVNSVU1hVlJVRVRM?=
 =?utf-8?B?M1NCUGpDbGR4RlN5cHdWN3U0bURSaU1KNlBOeTRpN2RHTnN0VHQ5MUdiVlVM?=
 =?utf-8?B?aWtUSnlIRjcydHJmUVJMRFp4M1ZydEJRaXdUNlA3VXAxa3lwcDdPYjZqb1dC?=
 =?utf-8?B?WHBxSCt0VXh3TjZzT3ZOajMrUWpMRUt6VU1HSG1tWmpBT2MyNDZxanRwaEFl?=
 =?utf-8?B?OGhtM0NwR0hnc0lSSmdIUmlDNEo4Vy9ZUW5kdUdlOHAyY0hkUXU1M05Ydy81?=
 =?utf-8?B?K3BJcDRYbG1nVFN0TGYzUlQwMkw2K2wzNzNZdlJVakRhL2V4NE5GeXdtcTh3?=
 =?utf-8?B?WWk0NGt3Y2RDRXdFbzhlV0xYNXNvUGZENnZiZjJYUVhhSkxUQy9SRUhXa3o5?=
 =?utf-8?B?UmY3ejAyekVrN21jcmFldmxDamo4Z29ydjNXU0NLRzR6WmxFY3BNanQyRlEv?=
 =?utf-8?B?aTZIVW41QnRtc3pTUXVhN0U2cHdMQjhuSTE2TytqcE8xaEd2QVhNZjRJUjRn?=
 =?utf-8?B?MVRTTXk5L2pZTGJTRUdTb2JBeU45NGdHT0JFVWl4elZaNkVFYnZJMWxlWmhq?=
 =?utf-8?B?dThvWFhOMUZJYVEvWFVBQXZhRnlQeHBoUEN3dmlHd05tSVpXRVFicFl6ZWJx?=
 =?utf-8?B?OTlMVFN3b3lkcHdYUmJzVkMvUS9kTlgwZEhUOWRjMUREVnhQWGxub00yb1hO?=
 =?utf-8?B?Y3VuUjRNaWF3MXp3dlpYL3NPZDVhbHhuVWMrb3pOVnAyR2Z6K3I0bytmSEkv?=
 =?utf-8?B?ODc0MVRtQjVzZUtDdC8yN3RwUjY2TDVBWXFkVmVHcHJiWVJvTUFzZGJBd3hG?=
 =?utf-8?B?WjQ1R2U3aGxkUXdKK2psdyt6cDdoWlE2QnJ2VkhDYXhrNWg2bHNZK0MwelUy?=
 =?utf-8?B?ekNYekkvS2NweFZTRUlGd1RIZHozL3c5Wld6KzY5VmRwQmZSR29HUklnK2pX?=
 =?utf-8?B?MEN4WWpJZlRjSEFXeU5sa3VYR0JKQkczTUV4K0paQVl0djhub1ZYc1dINVJD?=
 =?utf-8?B?cmU4TC9PNmlkcC9Ta1ZRUXA1VjIwOUl4N0c4SUxneENqdEVaTHJVNVFIMi9Q?=
 =?utf-8?B?STZ4SFpHSW9CNUJkZHV0WU1Rc3d2N2pLUXBwUktSYWp1R2NlaHdCNldjcm44?=
 =?utf-8?B?RlhKbGk0RDhSK3ZjbUxsZzh4U1pCMnovdUk0WHpxSjdVWWV0Nk1zZmRhc2pr?=
 =?utf-8?B?TDBkNGVLQWptazZUK09UU2FNR2pEVG9SeG5KbEUxbFMxMGVPcjBoWlI2allY?=
 =?utf-8?B?NWZUenlvdTd5cXFtcHFJZHFrWkdnL0xCK3lsaHBXM3JIUlhhdkRxZm1NczZC?=
 =?utf-8?B?c0F1azJVVG1NYk5hYUtvM2tSQ24wT2JIZmVxT1hZa2VLM1Q0YlMveUZxd3FE?=
 =?utf-8?B?Qks4a210NGVVcEpyYlZXSjI1UlJKdEdldzhrVFBoSWpnM2kybW5yM1JicnJs?=
 =?utf-8?B?c2FJRllnWTZncXAvVGQ4T0hFc3ZFaXM2bEd0eWJWRUVLbkVZZnIvVDlzRERL?=
 =?utf-8?B?eFBXNmh1YzBJalVmdGhjTEpWYUZvdEE3dVV1UjRxbndGRmZXamcrWklJNEVm?=
 =?utf-8?B?Um13SlJjV01SQ0prbDhZaVE3UWFuejZkVGdrSGtUMDhOOHpCMDB0OEo0RmJL?=
 =?utf-8?B?L0pVZkZ1NFMzNTJmZ3NsMzdkNXRFbE9TVVVSZWlkUDBielp3UHo3N1hXbmRJ?=
 =?utf-8?B?bGhMWFZ2S2hsdlc5dkxDVWtOYVdSSi9QdGJsYkFmbld1TXoyN2lZN2hBSVJU?=
 =?utf-8?B?ZjRHb2N4MERRMVlvaTJkT0ZFQU5Ud2FicTR4cXkyZzZWd3dPM1Y1NUhrQW5Y?=
 =?utf-8?B?SUlDNUE5YU84YitzNEJ6T2lFT1Izd2M1MVAzRmhRNFAzczh4T1hmSlhvM3hi?=
 =?utf-8?B?ZUVXazZEN3lVTVRKUTRkWUN4WjJLK1cwLzQvR3R3Vk1JdHVFUUFpb0NmbUNK?=
 =?utf-8?B?cmU5bXFtcEJtV0hQU2QrYVVSdCtDNFcxTzZuREdEZ3IxNEpvYXAwRUVub1Vy?=
 =?utf-8?B?UWk3Wk1HZlB2T1Qvb2I0VmhHcVRIK1ZuWE5Sd2w2ckFtSDBTaFRkUkVlVVE2?=
 =?utf-8?B?Znc9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 68cd5258-410d-461b-be05-08ddefd8255a
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Sep 2025 19:36:17.6743
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: TH2cS3VBiSnHho2thMMrW3V2mxZJ5uhWz2L5FHm6gpjVF8boP/QgYBTYDvHfZgORf+enf8EexSrS3Y1HE/zsfOHERwQpHoD70pTCU9zYSA8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR11MB7700
X-OriginatorOrg: intel.com

Konstantin Ryabitsev wrote:
[..]
> I don't have precise statistics, but I do have firsthand experience trying to
> make this work with git-patch-id, because this is how git-patchwork-bot works,
> and we can't match a significant portion of commits to patches.

What about something like this based on the idea that the same set of
files are almost never being touched at the exact same author-date
second:

time=0
for i in $(git show $1 --pretty=format:"%at" --name-only)
do
        if [ $time -eq 0 ]; then
                time=1
                echo -n "d:$i..$i"
        else
                echo -n " dfn:$i"
        fi
done
echo ""

For example:
$ ./lore.sh f10f46a0ee53420f707195fe33b7c235a1c0e48a
d:1752747497..1752747497 dfn:drivers/cxl/core/mbox.c dfn:drivers/cxl/core/trace.h dfn:drivers/cxl/cxlmem.h dfn:include/cxl/event.h

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 A0C8A1F3D58;
	Tue,  9 Sep 2025 21:05:21 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757451923; cv=none; b=I4VcA80kDqLOBszDSjEv4saTnm/e1MYgH9WPl2wZtmPxQu1L93PF6tJ+D1g7EZR/CWmUtNHN6vKlFHI6j/D+0GqOMaF2jG1MW8MFAvv5D53yJzFglpp1Nhhi3yktiKpgRHCNm6eMkZ8eCwcU8dQPGbQGKUiBQaeT+kEvEB8c8rw=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757451923; c=relaxed/simple;
	bh=vNOMPUmnU6XssDomYnLdwerx9PFNqm9nVH8sSFHH1Yg=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=cR0WnOZGE4FAXiFh/s4wzydEF9JBl9A/wglR657wNITB3VX6M+fQYtvXHNM3xoEt0GayZ1dKhO9z5ImMgQa0JYAvJumDNAsmN2zp+pF1d/3tW877JV4PGaPDJKWxV/GO+0voB3iAzkEfKVGqhd3yDfWa0L/IqrNSZES0Yg9El4M=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nv2qxJX/; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nv2qxJX/"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2AF1FC4CEF4;
	Tue,  9 Sep 2025 21:05:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757451921;
	bh=vNOMPUmnU6XssDomYnLdwerx9PFNqm9nVH8sSFHH1Yg=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=nv2qxJX/1dQbXHEsvXmOzlC9z8pH3VcF3Xpm0SBdLLfallO+LfF/LhbhwtEnlut5n
	 sgpGpzJOx9qodhlVZwY0VSyLrwyKrvE+u5gyHf4fgoe+6U0q2Kvh67lIr7AxW8e6Pc
	 NRHfm0pBJjiO5HkJwSVeBVlVlXxq+earYOScStWqVVBdYK5h6R//l01huM41oWRL1l
	 LuGkz6uWDi7rjuxu1KTRZNGQrWlH5AMDUQGqwopb6JrFXMZmVDhZNuzx7Yym7ZuSjD
	 YO2rEd9TpGNqS+MMC+SZUqoaB00xrouaEzHU1xS3mkJ26SjiRHETmzWK5P/cfddU41
	 hfqSIvxwSe/hQ==
Date: Tue, 9 Sep 2025 22:05:16 +0100
From: Mark Brown <broonie@kernel.org>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>,
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
	Jakub Kicinski <kuba@kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>, dan.j.williams@intel.com,
	Caleb Sander Mateos <csander@purestorage.com>,
	io-uring <io-uring@vger.kernel.org>, workflows@vger.kernel.org
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
Message-ID: <22523fec-5745-40f9-8242-1c340bac843a@sirena.org.uk>
References: <5922560.DvuYhMxLoT@rafael.j.wysocki>
 <20250909071818.15507ee6@kernel.org>
 <92dc8570-84a2-4015-9c7a-6e7da784869a@kernel.dk>
 <20250909-green-oriole-of-speed-85cd6d@lemur>
 <497c9c10-3309-49b9-8d4f-ff0bc34df4e5@suse.cz>
 <be98399d-3886-496e-9cf4-5ec909124418@kernel.dk>
 <CAHk-=whP2zoFm+-EmgQ69-00cxM5jgoEGWyAYVQ8bQYFbb2j=Q@mail.gmail.com>
 <e09555bc-4b0f-4f3a-82a3-914f38c3cde5@suse.cz>
 <CAHk-=wgfWG+MHXoFG2guu2GAoSBrmcdXU2apj+MJpgdCXxwbwA@mail.gmail.com>
 <ad587c82-cc9c-43ef-89c5-d208734a4c7f@suse.cz>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="mbJsZ2iIUchEgbGB"
Content-Disposition: inline
In-Reply-To: <ad587c82-cc9c-43ef-89c5-d208734a4c7f@suse.cz>
X-Cookie: Ma Bell is a mean mother!


--mbJsZ2iIUchEgbGB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Sep 09, 2025 at 08:22:05PM +0200, Vlastimil Babka wrote:
> On 9/9/25 20:14, Linus Torvalds wrote:

> > But yes: please do continue to add links to the original email - IF
> > you thought about it. That has always been my standpoint. Exactly like
> > "Fixes", and exactly like EVERY SINGLE OTHER THING you add to a commit
> > message.

> Fine, maybe b4 could help here by verifying if patch-id works on commits in
> the maintainer's branch before sending a pr, and for those where it doesn't,
> the maintainer can decide to add them. It sounds more useful to me than
> adding anything "AI-powered" to it.

I think ideally if there's tooling for this it should have both a
verification feature like you mention and also be supported by b4 mbox
so that you can say "b4 mbox ${COMMIT}" or whatever and have it download
a mailbox like can currently be done with a message ID.  That'd keep the
usability we currently have, the tool could look in the message for a
link and use that if it needs it.

What might be especially usable for applying/publishing would be
something that can be used either in a hook or more likely in scripting
that'll take the Message-Ids from git that people currently use to
generate the Link: tags and discard them if whatever the tool usually
uses to find mail archive links works without them, or rewrite them into
Link: tags if not.  The tool could emit the warning you suggest when
leaving the links in.

--mbJsZ2iIUchEgbGB
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmjAlosACgkQJNaLcl1U
h9DYdwf/QGLJUhrIM3VlMAceJ2nDDxbEd/TpA0FpuOJMTcoFYsVjS54QrVWncdzf
RgNZcdu3oC6bRv9bK5wczsSyJ0QCvDNzKBAdpanAD/jhiUKqLMVZeORCYhDmEjn7
iMh5Wi6MMymjVq6MiK3a0IgIYpd+IAUIkKENdbMUlb6PU6njfgGfRfmS1ehM8XNS
JFhB8SrK+yZOWbes9J6IZ3ZRnpKLpWY6jrcp0867SXBirPUHNUJXV5Iqd+utS4e/
S3AhH8OeuVtYjrJN6ISOThWpT925V8VGV3jCl182GJU71BCLQQnJJVx1YxGT+s61
Ta3InC4Yb6dhfVuAFQ+EImWFB/Pbxw==
=Wkaj
-----END PGP SIGNATURE-----

--mbJsZ2iIUchEgbGB--

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15])
	(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 E3A0B1E32B7;
	Wed, 10 Sep 2025 01:12:22 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=198.175.65.15
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757466745; cv=fail; b=cwUTLNoT5WnChVpcu4Yxe4AjerfzQNCHhvRzTMFMooTNcFvpkYLJ1vY6JtnAFnlYPw+v6bGhSE+sV7TeCcR3mjtAlFlwggDhWjdOzM6jKMhkFC3inbjtsZRj2y16eupllXIqvOWvBI9UXyjoPqFDfqKcA5DfqKHlNIlsKNho9QE=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757466745; c=relaxed/simple;
	bh=BeiPWTNQdqW5Q7sUzz1Dl0x60rbAPm/GEnx+lQBdoLg=;
	h=From:Date:To:CC:Message-ID:In-Reply-To:References:Subject:
	 Content-Type:MIME-Version; b=VNiUUsP7R8wMGKvc3sy9eXr97eN4/PB+DzC4PjYQ8gb4ukTU2tZtzD4nV6VLnNajPqquuBA9M5UMwd4inrFHz7N/ULsYbIzNFedRSz50InHUB2vQvNk2/AY98sZHVYugXLOM86lTrZJBCqPA8WhIRAKtRQq1+ce/r7c2qtXx3K4=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=gjUau4Qx; arc=fail smtp.client-ip=198.175.65.15
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="gjUau4Qx"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1757466743; x=1789002743;
  h=from:date:to:cc:message-id:in-reply-to:references:
   subject:content-transfer-encoding:mime-version;
  bh=BeiPWTNQdqW5Q7sUzz1Dl0x60rbAPm/GEnx+lQBdoLg=;
  b=gjUau4Qxaq0zhJ0Tq3Rt5qp/+Ws/lkYfVqhhjAnCyuBNP7VwjGXcQ3qG
   30Pk/JTD38KECBPKLVXIxar8WsiY8KcYZEiAoZ7fJOosBMOUNdpxQJpNA
   waS5De6uTd9chW81u/1f3bYgYNn4En7yFKQhx9GsxNf1pCV1sjDW7Wzl9
   CMBNHJK0rLfPcboLqeJbrZUTgrNb4E1OOSCIP0jO0Twx53uWkyiI/VE4h
   gtWeu5aoTGKtpmEyjiaRj0LNxJ9IGeW1cLnhr0vY7y1ohfZjzwJ/FteRb
   vJpSXdxJJ5x0xV9Hlf+BeKkJIkQc9UbV1LOtAoyrPgMcjiex3xaKojmqb
   Q==;
X-CSE-ConnectionGUID: wWmVhkoOQdaL6ljD7tQ9SA==
X-CSE-MsgGUID: viZLx6HTQTe/u0Nzy756wQ==
X-IronPort-AV: E=McAfee;i="6800,10657,11548"; a="63397515"
X-IronPort-AV: E=Sophos;i="6.18,252,1751266800"; 
   d="scan'208";a="63397515"
Received: from fmviesa007.fm.intel.com ([10.60.135.147])
  by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2025 18:12:22 -0700
X-CSE-ConnectionGUID: 4Yb0I16vRkSPwCdGtn/grA==
X-CSE-MsgGUID: EfvGRXFWT1GPO4RkIhPexQ==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.18,252,1751266800"; 
   d="scan'208";a="172834383"
Received: from orsmsx902.amr.corp.intel.com ([10.22.229.24])
  by fmviesa007.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2025 18:12:21 -0700
Received: from ORSMSX901.amr.corp.intel.com (10.22.229.23) by
 ORSMSX902.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Tue, 9 Sep 2025 18:12:20 -0700
Received: from ORSEDG902.ED.cps.intel.com (10.7.248.12) by
 ORSMSX901.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17 via Frontend Transport; Tue, 9 Sep 2025 18:12:20 -0700
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (40.107.223.88)
 by edgegateway.intel.com (134.134.137.112) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.2.2562.17; Tue, 9 Sep 2025 18:12:19 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=TXpnsVD0DfbRk3I0Jnjj2l/SH8hDGBy2MVA0GjSbwDKbflkwaKUj6lGUjM6cVbzFH3gFrYqsyKP6iBr33DY4VxKMnEHrkE4jDHxxHzLRwTUrYTXHfcwZhOlL/lS/zd96+Yjd6gXvr0AzlqzkJpAnlzKirCw3DurquGziqZ2+JZZCk74RF3Pjbb+TIhq466C4Rg9i+wgBvxaJTYR87PBifmAeE9c/R06ZCxwModBXRBnTLyEoaZh9USunmHss+6RwzUtipc5EorkoPlccSxcd/cha4sFiKShjSNuJgUXxCZ+dmhVmGU9FUvd+03Gh6zBHQOLzQw2rPvHShiLQqRRLxA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2krcDivsz2hfsfGYakF95j69YiMWq/30UQCNxXtuhY8=;
 b=u8PEsv1sFFS+8KIShnl8rvRGG8o3ZHdUW14jem/Ix29qFKGoBZkyDqtaNuIgNct4CJbUR98UVOHEc9y1KxRa7OX777YIxJyLT5I7udam+lw+B90XUOk38WZafsetUZ2p2vYKn7os82w2CnqnxRQttvD2EMIDiC2sACQH/+Xb0txwOBtg7SVSSOiKb2y7slrwIWx6GiFihMNgYC07vdNHNrb0OZ0QqjUu4mamGVgkEr+T2LiQXNSZ4var1RcltZ2WiC2HHTXuhSZ2w+n1dfUBSCFiMX5GZkhbVqpv0iFwTHWoniffei74LQCW9sNDMDBOsl0qEx/c+1xvjTZPdQF41g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;
 dkim=pass header.d=intel.com; arc=none
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=intel.com;
Received: from PH8PR11MB8107.namprd11.prod.outlook.com (2603:10b6:510:256::6)
 by DM4PR11MB5262.namprd11.prod.outlook.com (2603:10b6:5:389::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9094.22; Wed, 10 Sep
 2025 01:12:18 +0000
Received: from PH8PR11MB8107.namprd11.prod.outlook.com
 ([fe80::6b05:74cf:a304:ecd8]) by PH8PR11MB8107.namprd11.prod.outlook.com
 ([fe80::6b05:74cf:a304:ecd8%2]) with mapi id 15.20.9094.021; Wed, 10 Sep 2025
 01:12:18 +0000
From: <dan.j.williams@intel.com>
Date: Tue, 9 Sep 2025 18:12:19 -0700
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>, Linus Torvalds
	<torvalds@linux-foundation.org>
CC: Mark Brown <broonie@kernel.org>, Jens Axboe <axboe@kernel.dk>, "Vlastimil
 Babka" <vbabka@suse.cz>, Jakub Kicinski <kuba@kernel.org>, "Rafael J.
 Wysocki" <rafael@kernel.org>, <dan.j.williams@intel.com>, Caleb Sander Mateos
	<csander@purestorage.com>, io-uring <io-uring@vger.kernel.org>,
	<workflows@vger.kernel.org>
Message-ID: <68c0d07372c8d_4224d100dc@dwillia2-mobl4.notmuch>
In-Reply-To: <20250909-impetuous-swine-of-chaos-2aa9af@meerkat>
References: <5922560.DvuYhMxLoT@rafael.j.wysocki>
 <20250909071818.15507ee6@kernel.org>
 <92dc8570-84a2-4015-9c7a-6e7da784869a@kernel.dk>
 <20250909-green-oriole-of-speed-85cd6d@lemur>
 <497c9c10-3309-49b9-8d4f-ff0bc34df4e5@suse.cz>
 <be98399d-3886-496e-9cf4-5ec909124418@kernel.dk>
 <CAHk-=whP2zoFm+-EmgQ69-00cxM5jgoEGWyAYVQ8bQYFbb2j=Q@mail.gmail.com>
 <af29e72b-ade6-4549-b264-af31a3128cf1@sirena.org.uk>
 <CAHk-=wiN+8EUoik4UeAJ-HPSU7hczQP+8+_uP3vtAy_=YfJ9PQ@mail.gmail.com>
 <CAHk-=wh2F5EPJWhiEeW=Ft0rx9HFcZj2cWnNGh_OuR0kdBm8UA@mail.gmail.com>
 <20250909-impetuous-swine-of-chaos-2aa9af@meerkat>
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: SJ0PR03CA0148.namprd03.prod.outlook.com
 (2603:10b6:a03:33c::33) To PH8PR11MB8107.namprd11.prod.outlook.com
 (2603:10b6:510:256::6)
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR11MB8107:EE_|DM4PR11MB5262:EE_
X-MS-Office365-Filtering-Correlation-Id: 3dafba27-f913-4390-6b49-08ddf007161a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|366016|376014|1800799024;
X-Microsoft-Antispam-Message-Info: =?utf-8?B?S3puWWcyOGRZM051eEZSN0tDOVlqSS91MlQya1BVdnoxVlhRTFJLZUtsRml2?=
 =?utf-8?B?N3F2aThuVWx4MmR0Z3BsOVRLWWhiRHgrTHJEc2FINENDZlNhQVcrRUVEbk9I?=
 =?utf-8?B?TzV6WURZQVJ6cWtPaFVGMnh1K2ZkdEpMOC9od2NqUEMzOVpEc3doVzNNS011?=
 =?utf-8?B?aWRUMzVrMnc5U096THlrelNhRUd6WXZMekRMUmw4TVBia0ZCa2NtU3ZwVXZp?=
 =?utf-8?B?UXY1MHVGTWxZOUFrRFUxVEdJcnpzVitZUmpxYlFtWmdNMnRaNExFWWxud1Fx?=
 =?utf-8?B?cE9PVXB4MFBwdGd3WEpOVThqNWl6MVI1biswOWdNK3h0dGxnL0Z6UjVCdmVv?=
 =?utf-8?B?VW5TQkJrcWI1MTU0L1c1a1JleDBrN2hJY09EUVVYNWcwK1JXeVk2U2lBUFlD?=
 =?utf-8?B?Vzc3VXVWVWYwMCt2NDF2YXdVeXpwbWRTNlhMMkdpempHRS9vNHFuSGJkcG1z?=
 =?utf-8?B?TDBGU0gyVTM4L2tQQTdjNFZYcjl3WE9JZEJZdzdsNE4vNFhROFFwaXlXVW51?=
 =?utf-8?B?a3pTNUFmeHpENlVVY05hVzlMcXVrbjY3SVU3a2N2UGYxUlBmREllcnFQTzJq?=
 =?utf-8?B?dmNCRFozbWZNb2FSVmZ0enhGNDFuU0F2Q2xjYXFJY1lwQmxia0hDcUwzUEx3?=
 =?utf-8?B?L3U2aFdzT3dPMjFjaHk0aVMxc05uQTlqclM5Z3JvNnY3NDJUMHhxZDlRU0Ev?=
 =?utf-8?B?U01BRkNoemdHSGhuRzNqbFlrdWIxaFRNOGlEamhjZExQankrUFV1SkM1V1BM?=
 =?utf-8?B?c3J1UHdBWVhHQy9JZ1B4b3hVM20wVlUwYVdrTzRwekF2MEtkeXJrMHJ0WUl6?=
 =?utf-8?B?dVZoWDZINDNudWF4ODlwcEFFaU5LRWdUOTdLMi8vSlZhOUI4eTZ5OFlUdk8x?=
 =?utf-8?B?RjVlT1l0blZCQ2l6YnlCeGV3NExQcjFKYlQ5cnRxQzBKMHhyTlNBZVVIRjBI?=
 =?utf-8?B?OGcybldOa2prdGs3QlN2TWFnQmJ6dlBUcTJlREx5bERoNVVDRDRNRHhqb3NE?=
 =?utf-8?B?eGFpKzRIWlJSUFdkb0xsR3Q5OUYzUmFtM3A5amlvcGJrUlVpcHBCWWdEaHpo?=
 =?utf-8?B?b204OVhDeW9MTTgyNmVaUUpwUkMxUXUyRGFtZ3JHZlMzcUVubkhvRDRRalBa?=
 =?utf-8?B?ZG43WXZqTk1STVpKTUpIWUE5dFovckJzcGxheSt4ZVptSFBrbHp3WjJ1blJL?=
 =?utf-8?B?ME1vRHhOVXdTR3p6aW50dS96bUZrd3ZoSUxlZ2Y3V3VZOHVrTUJ3N2VvWWls?=
 =?utf-8?B?Z2M1aCtjTUd2TnVWODhRMVlBZkdqWjU3Zm9rVDMyYkw5WXBDTU5kY2FRRDd2?=
 =?utf-8?B?SERsdlRMNEJwNHNUSkI1T2hxNHA5UjNhODhObXh1bkN5L1ZYUEtHcm5aZUts?=
 =?utf-8?B?Wm1JQWpLTDBBZitzeElDaU5uNXd3dHRHR2NVTlNZSzhQNmViUEVVcjVYeVRY?=
 =?utf-8?B?SU02V0FscC9kemhnVHREczgvazlGWGdMb1FpR1VMNlFkd1lXNFNKakJ1U1NS?=
 =?utf-8?B?OElFM1FrRktHZHQ0UStWUjByZkRNNUVQek80UU9MN25mczRSczMwS2ZZSHZa?=
 =?utf-8?B?dUQ1dmhBZzBHc3EvVUNHUEJWaTc1N3hxeFhGa01UTnRtbElSb3RBOEF6bW1z?=
 =?utf-8?B?SXZZaklLMWM4UUlFOENPQytzYXJaY1VYdTNQcFZaeVAvY1Q0Nm9KQm45ZVNW?=
 =?utf-8?B?azJMYWRTYVhhUXg1Q1M2dzdOMVZISkc3ZGxkUDhSQ1d5NWtNZkI3WCsxaDFx?=
 =?utf-8?B?QTdjWXVRUXFNY21rQWV1RDcxTHpYTHc3OEVqYlFCVW5OU0tsZUMyZVZqTzla?=
 =?utf-8?B?ZDM1a3M5b0tBdlE5SEtza2JxUytZaFl5SlUyQXJQa3EzRS9RZHV0dzR2N2dw?=
 =?utf-8?B?NXdwYy9mV05UQnMycWc4bkxFeE1ONTdoOEVMd1dFYlVrOGx3UnJ4Qkg0U3ho?=
 =?utf-8?Q?lsylhn3ryoA=3D?=
X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH8PR11MB8107.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(366016)(376014)(1800799024);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WFlTOEM4UlUycDcxNndwQmhhSlpQZ1BYRndwektWTlNvTXNuMzR3SXlmWnBj?=
 =?utf-8?B?YmFDcDNkajJnYTBTMUd6TTBxQUFjWENmTmtoZXl4Vy9KcDhnc2h1T2xRSkRV?=
 =?utf-8?B?bjhVb0xjMUVuRmg4VWRGdGNDL1hUajhEKzFWdlp1TVZUbUVYNTk3cUxmcWNa?=
 =?utf-8?B?MTU0MUZyUlZRaCt1UDMxazVlZU1Ub0RqNWhJMmhUS0RvamtWNEdoeGFNaVBr?=
 =?utf-8?B?U3VFWGFhSlorcmphVmMwV3BOd1dJbHJIbFZyZmdmWGE3TldHQWZJWXZhMC9J?=
 =?utf-8?B?SjFLMm45azBWY0o4MjFkSllvaTBYNnNSc2ZZVzN2Mzk2Q0pLTkt5S1NjQlRk?=
 =?utf-8?B?ZXRPdC9WL1RzQjlWY3FLQ3VtTzlSVzBha2xmYzhMVWcvUEhzdkZramtDRTRN?=
 =?utf-8?B?WEJYYVhyeGcrOVNGakpISC9ReWI2K25GSVdoeEFlNzJmUzA5NUlpUHF2NTla?=
 =?utf-8?B?d0RReTR2bUpaRkNxUG9DcXR3Qk50YmVvYm93WE9jTThBNVIwQ094dnlWS20z?=
 =?utf-8?B?azhSTXdILzEvK1AwS1V5TWtLT0xmMHNKcWhkL2kySG15cEptRWcwaUh5Nms4?=
 =?utf-8?B?dVlQMDFNUU9CUkxUL0UrWEMxUHl1MGZhb1MwNzJGc1R0ZXlycW9jd0ExdEls?=
 =?utf-8?B?Z0pNS3ZYTng3YzFDS242UXFJcEdIckwySjVEaUlSZURtcFZiQkVKWFZOSDVT?=
 =?utf-8?B?b0k2RDJxQlR0OWpOemUwRW9FVlM2RWlML2NvaE1RRFFrRWFtc2Fwa2p1U2k4?=
 =?utf-8?B?c0lXdEgzcVQ4T1FyUU56eXRQTklMenVFa0hvMkdPVkYvRFpTWHNFREt3cVpn?=
 =?utf-8?B?K080bElHSW9TR1F0NVFRUkl0cmdCbFM1aWNIMHQ3Wlo1VUMvYnJvRUkrOVlB?=
 =?utf-8?B?Rkk2R1NXQS9JMS9WbDNWbUl1aFhOeGo5UklTU1NKWnFJZ2wzTWpXYlhxSVEv?=
 =?utf-8?B?U29QemRydG9VLy9vc1J0bkVvQTY3cTczVkR6a1FtOHpTVkFCeTVVeDQvRldS?=
 =?utf-8?B?ejljdXFaM3BlcXpNT1MyNnBWM0UrNzdBZmM0WTh1Z3hvVlNXU2VINStPZmJP?=
 =?utf-8?B?VElBSnJ1OEtWL1dzVWxJUm5tRzJmTnJrYWorMng0Q2VOSXZrWmhkb2toY2s3?=
 =?utf-8?B?alo0SXlvNitFMTFJV3JYMWtDaXR5c1NVZnFPcGpNZnFvczVLQ3JyQjBZOE80?=
 =?utf-8?B?ZWdzUFA5VVlQbVlucmZINzRaT3Z2VzdBMmkzR20xRnhqSjV6R2hqY2Qyb2tU?=
 =?utf-8?B?MlR5RkkrbDduUzN0dVVoWFlra0twMVBJZ1BDeWl3VnhNdEpCNXN3bHlidXZq?=
 =?utf-8?B?bHVCZjMyajV1eWZrVnFHcGtNcjRZakNBRkphYTJOR24wNEhYSjY1NVdabndZ?=
 =?utf-8?B?cWdKNUhTUEhDMHlJYnZnL1g5WDJVWG5nU0cvM3R3SHpOclBuSFAwOW1ORXBx?=
 =?utf-8?B?eVBPbHk1M1BCbkRnUGNnd2IxVXZPR0EwL0dDcGpHODg0UHdZMWlSMFNJVHNz?=
 =?utf-8?B?ZzhiZUJ6Ky9Eb3lVeWFhL1ZCRW1uNVRBTStjMnVOb2U3QVY0eTA0VzhzeURE?=
 =?utf-8?B?c1BUWnh6YXJmaTVmUE5acit3b1k0OHpnL09YYTdITzFyMzRLWHoyUktsYkFB?=
 =?utf-8?B?bVZFajZHNnorYjhDNHdyK3JWVEE5UE9BaCtPU0tjRk91VHJFQm82cGtGY2ts?=
 =?utf-8?B?eUZ4OGpIeW14R2h0SXRwNTc0dVY0T0tTOFM3UCttdHFiUzBkYjFteEswa0tD?=
 =?utf-8?B?STN4NitSUXVKZ0FpRjdWeHpQMDVheXNWdzNhMG1zR2ZxQ2JhaTZGK09ad000?=
 =?utf-8?B?c3AxaHYrdVRSOFJ6SGM4Sktkd2VYUFdqV2didVlHcGh1ejNiR0l4bmgwdkZF?=
 =?utf-8?B?T1NWc1Y2ZDhVQWorZUdzY2lHNHpPRUVBSUs0cHBTaDFPcFhRTUdscEt2eTdz?=
 =?utf-8?B?S0tkeEtWK3ZSVlBJWUZIa1V5ekdUZFlzYzMzck9ZWUNuckVhWTkvbmxBVzNF?=
 =?utf-8?B?Wkx1M2VQeG00NFd3WkJVU2NEK2RiY1Q1VzZUc1JOdnVNTXIyL0lVRDl3Q0lt?=
 =?utf-8?B?UG1HQXIvQ1NsV25xTnJsT3FSei9NbFdYSHFnMmtrRlQ2MHY4S1FhQkZQNjdI?=
 =?utf-8?B?bm5oOFNtNVBiTzd5dDg3eUFmcWszb3FzajJVZUJzNHBJcXEvbEtJeFduNVlt?=
 =?utf-8?B?RlE9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 3dafba27-f913-4390-6b49-08ddf007161a
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Sep 2025 01:12:18.4482
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: +Ux1Chh28gQ+2lyzN75s4fDwpASQ+3lKikjmLV0wqCOOSm4aWM1CF50Cq8oaczOUtFFHRRGQ4XbjEXaMwutZYKCAk2rbpYrgZ3CTzqQrgJY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB5262
X-OriginatorOrg: intel.com

Konstantin Ryabitsev wrote:
> On Tue, Sep 09, 2025 at 10:58:53AM -0700, Linus Torvalds wrote:
> > On Tue, 9 Sept 2025 at 10:50, Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
> > >
> > >    patchid=$(git diff-tree -p fef7ded169ed7e133612f90a032dc2af1ce19bef
> > > | git patch-id | cut -d' ' -f1)
> > 
> > Oh, and looking more at that, use Dan's version instead.  You almost
> > certainly want to use '--stable' like Dan did, although maybe
> > Konstantin can speak up on what option lore actually uses for
> > indexing.
> 
> It uses --stable.
> 
> > And you *can* screw up patchid matching. In particular, you can
> > generate patches different ways, and patch-id won't generate the same
> > thing for a rename patch and a add/delete patch, for example (again:
> > the traditional use case is that you generate the patch IDs all from
> > the same tree, so you control how you generate the patches)
> 
> We can't control how the patches are generated by submitters. If someone
> generates and sends them with --histogram, this won't work. Here's an example
> right from your tree:
> 
>     $ git show 1c67f9c54cdc70627e3f6472b89cd3d895df974c | git patch-id --stable | cut -d' ' -f1
>     57cb8d951fd1006d885f6bc7083283d3bc6040c1
> 
>     $ git show --histogram 1c67f9c54cdc70627e3f6472b89cd3d895df974c | git patch-id --stable | cut -d' ' -f1
>     47b4bfff33d1456d0a2bb30f8bd74e1cfe9eb31e
> 
> Or if someone generates with -U5 instead of the default (-U3):
> 
>     $ git show 1c67f9c54cdc70627e3f6472b89cd3d895df974c -U5 | git patch-id --stable | cut -d' ' -f1
>     0b68dd472dc791447c3091f7a671e7f1e5d7a3d2

Is this a matter of teach git send-email to generate a header, e.g.
"X-Patch-ID:", for a given stable diff format convention? That lets
submitters use any diff format they want, but the X-Patch-ID: is
constant. Then "git show $diff_opts_convention $commit" becomes more
reliable over time.

It still does not help the problem of maintainers massaging patches on
their way upstream, but patch.msgid.link does not help that either
because that Link: is not the patch that was merged. So if you care
about automated tooling being able to query lore for commits, the
maintainer simply needs to push modified patches back out to the list,
or accept the consequences of disconnecting the commit from the lore
lookups.

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 70DB72E403;
	Wed, 10 Sep 2025 01:33:05 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757467985; cv=none; b=HoZu3bz2L8IHmhHg4V80cesHFzzhH86jP9pLZe4rHXzstFLPpoEtUpuAzEcxUVtjdJ7GUc7MX0GjOwYW0LDAAhcvvGpIdG9nRDTwvxPdzJLNJnH/0W5Dhd9+zT2CuPAqftDIiZpM1iv+GuAykAIdQHNDXx+9bp26gm+sKWs5ymo=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757467985; c=relaxed/simple;
	bh=baLUnX0AXCRDgPI3/TGamIRtNzlWQifunDhD/ve97zQ=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=VbdRQxyy19TJtOhzuiOCP4XilMFqAHHTG9kdioHd1OlzUCSW83mxbzFOFnTDLKQ9rRsfj7CJeNwuszQTpn9RgUPkUpr+IKi+NIt+zCUJ2iSDMmwI4w5Y5xFRYoVoZf5JEh/xnYSXOo0DPPDuFgCfhvPpAmj4IYOLYXA4b1ToDzE=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=S4wI8OdG; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="S4wI8OdG"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id CAF82C4CEF4;
	Wed, 10 Sep 2025 01:33:04 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1757467985;
	bh=baLUnX0AXCRDgPI3/TGamIRtNzlWQifunDhD/ve97zQ=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=S4wI8OdG1BeoiHimCAH3TcunFuCJWGI0i7Smfb4Or4PhW/TWe8AU5T7hcVv1kZFmh
	 XqP3Z9WnlZuSuaL1wuF97YHIaYj+/Btjg12kQ3ShAAjXk5X3Ux3V2rBTwaB0YxD2wh
	 eHGim5098H8i0/RucAC4ih/QM+1haqzuzjy3u5Bs=
Date: Tue, 9 Sep 2025 21:33:02 -0400
From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: Mark Brown <broonie@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>, 
	Linus Torvalds <torvalds@linux-foundation.org>, Jens Axboe <axboe@kernel.dk>, Jakub Kicinski <kuba@kernel.org>, 
	"Rafael J. Wysocki" <rafael@kernel.org>, dan.j.williams@intel.com, 
	Caleb Sander Mateos <csander@purestorage.com>, io-uring <io-uring@vger.kernel.org>, workflows@vger.kernel.org
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
Message-ID: <20250909-fast-mastiff-of-agility-55c3a7@lemur>
References: <20250909071818.15507ee6@kernel.org>
 <92dc8570-84a2-4015-9c7a-6e7da784869a@kernel.dk>
 <20250909-green-oriole-of-speed-85cd6d@lemur>
 <497c9c10-3309-49b9-8d4f-ff0bc34df4e5@suse.cz>
 <be98399d-3886-496e-9cf4-5ec909124418@kernel.dk>
 <CAHk-=whP2zoFm+-EmgQ69-00cxM5jgoEGWyAYVQ8bQYFbb2j=Q@mail.gmail.com>
 <e09555bc-4b0f-4f3a-82a3-914f38c3cde5@suse.cz>
 <CAHk-=wgfWG+MHXoFG2guu2GAoSBrmcdXU2apj+MJpgdCXxwbwA@mail.gmail.com>
 <ad587c82-cc9c-43ef-89c5-d208734a4c7f@suse.cz>
 <22523fec-5745-40f9-8242-1c340bac843a@sirena.org.uk>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <22523fec-5745-40f9-8242-1c340bac843a@sirena.org.uk>

On Tue, Sep 09, 2025 at 10:05:16PM +0100, Mark Brown wrote:
> > Fine, maybe b4 could help here by verifying if patch-id works on commits in
> > the maintainer's branch before sending a pr, and for those where it doesn't,
> > the maintainer can decide to add them. It sounds more useful to me than
> > adding anything "AI-powered" to it.
> 
> I think ideally if there's tooling for this it should have both a
> verification feature like you mention and also be supported by b4 mbox
> so that you can say "b4 mbox ${COMMIT}" or whatever and have it download
> a mailbox like can currently be done with a message ID.  That'd keep the
> usability we currently have, the tool could look in the message for a
> link and use that if it needs it.

Yeah, this is actually a neat idea -- I'll put that on the menu. We'll try
both --myers and --histogram when looking it up and then try a few other
tricks if we don't find anything (query by subject+author, etc).

I'll let you know when it's ready to test out.

-K

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64])
	(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 120B73126B5;
	Wed, 10 Sep 2025 10:14:06 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.167.242.64
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757499248; cv=none; b=XK0Aw+uitbjPjlH4sz4hDuraN3bwRfuQWhyUJDoF/E+a4bxwDZNtQN1AVsf1a4hRVchDpbtxw4U98wAuKgyEswtLw0bWP2Q0SKlO/+pm976z4JvZYD2d0T26PgEvAiEtva6k++hEkAAV+pG8dqVAUgE11KpPHszEijRPUJzIUcM=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757499248; c=relaxed/simple;
	bh=Ju9IhFGWUedr02UBHhYV41hTSD6lcTpnCP+UJ4XoX74=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=HQme6MFRAYmjb1uOyLg3uUaaQBgQ9PkAHp4Gt71557rpgSgqe8vI4m1KGcpsoMjGjFUE7bzTT4OdJ7uOIdiNLbg7H2TwZ+iIxKzA4l4xqq8F4E7P29NfxwWcunyX8FIJlkHiX0oRyikVse9fgSVbdGq33gOqVnzXkVXIoECN/NI=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com; spf=pass smtp.mailfrom=ideasonboard.com; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b=J1toTbC0; arc=none smtp.client-ip=213.167.242.64
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ideasonboard.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="J1toTbC0"
Received: from pendragon.ideasonboard.com (81-175-209-231.bb.dnainternet.fi [81.175.209.231])
	by perceval.ideasonboard.com (Postfix) with UTF8SMTPSA id 9546AC6F;
	Wed, 10 Sep 2025 12:12:51 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;
	s=mail; t=1757499171;
	bh=Ju9IhFGWUedr02UBHhYV41hTSD6lcTpnCP+UJ4XoX74=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=J1toTbC0HaVbEB35LQl1Cf0s6f6QX+8pxZinL9WhLEOBzqQZ/wGr4FIhZIDZ2pcQp
	 GB74W7wm2vDjcIpe7/ZHB4OucQtDc8T2uRDotbR1R6VQfTbrgE/VyMeiTIVSolWgZO
	 s+FHco2w6L1glxDVS8J6nDO68ljjMV3wWOrFVgms=
Date: Wed, 10 Sep 2025 13:13:42 +0300
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Sasha Levin <sashal@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>, konstantin@linuxfoundation.org,
	csander@purestorage.com, io-uring@vger.kernel.org,
	torvalds@linux-foundation.org, workflows@vger.kernel.org
Subject: Re: [RFC] b4 dig: Add AI-powered email relationship discovery command
Message-ID: <20250910101342.GD20904@pendragon.ideasonboard.com>
References: <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <20250909163214.3241191-1-sashal@kernel.org>
 <20250909172258.GH18349@pendragon.ideasonboard.com>
 <72dd17ad-5467-49d3-9f40-054b1bf875d5@kernel.dk>
 <aMB3_VgB4mwp-bzP@laps>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <aMB3_VgB4mwp-bzP@laps>

On Tue, Sep 09, 2025 at 02:54:53PM -0400, Sasha Levin wrote:
> On Tue, Sep 09, 2025 at 11:26:19AM -0600, Jens Axboe wrote:
> > On 9/9/25 11:22 AM, Laurent Pinchart wrote:
> >> On Tue, Sep 09, 2025 at 12:32:14PM -0400, Sasha Levin wrote:
> >>> Add a new 'b4 dig' subcommand that uses AI agents to discover related
> >>> emails for a given message ID. This helps developers find all relevant
> >>> context around patches including previous versions, bug reports, reviews,
> >>> and related discussions.
> >>
> >> That really sounds like "if all you have is a hammer, everything looks
> >> like a nail". The community has been working for multiple years to
> >> improve discovery of relationships between patches and commits, with
> >> great tools such are lore, lei and b4, and usage of commit IDs, patch
> >> IDs and message IDs to link everything together. Those provide exact
> >> results in a deterministic way, and consume a fraction of power of what
> >> this patch would do. It would be very sad if this would be the direction
> >> we decide to take.
> >
> > Fully agree, this kind of lazy "oh just waste billions of cycles and
> > punt to some AI" bs is just kind of giving up on proper infrastructure
> > to support maintainers and developers.
> 
> This feels like a false choice: why force a pick between b4-dig-like tooling
> and improving our infra? They can work together. As tagging and workflows
> improve, those gains will flow into the tools anyway.
> 
> It's like saying we should skip -rc releases because they mean we've given up
> on bug free code.

I really have trouble thinking this is a honest argument. We're
discussing the topic in the context of a project where we reject
thousands of patches all the time when they don't go in the right
direction.

Throwing an LLM at the problem is not just a major waste of power, it
also hurts as it will shift the focus away from improving the
deterministic tools we've been working on. Using an LLM here only
benefits the companies that make money from those proprietary tools.

> Perfect is the enemy of the good. You're arguing against a tool that works now,
> just because it's not ideal, and to chase perfection instead. I'd rather be
> "lazy" and skip the endless lore hunts.

Nobody will stop you from being lazy or anything else. I'll however push
back against the bad influence on others.

-- 
Regards,

Laurent Pinchart

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 CA964313E3A;
	Wed, 10 Sep 2025 10:55:57 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757501757; cv=none; b=VSW2Ris1nUT8d6gOHlV/FVl2DSlhF9Q2k8XXKAe2FNLm9SWEyxyak00vTb2oMfJWbJYeFe7Cwf9uwAwADfJj/K/gzaYDRgL2Flya3/UuxPhatIp3UajyW5o0ThwRm+4x7mteRIp5OnQw70xgNOxHn/QbwIezgl2Z0bxCjMuHsJ4=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757501757; c=relaxed/simple;
	bh=tsSBIpHdakcXHPvAGSyYjic7W9pbJfh7J6hCd32e9+g=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=LVIzs9MU8QM4Wp6qJ3DtpuldH8ayVNQeInXp6WUcGgNEvCBw5PKwdGrqsiCzrw7pSicPjeqwvRJjsc33k8JTo/pPgBfvAYKAfjJ9G9iLXKDxpyQDqjqPqdUesDq2CihOWoXgA6VTPF/1/Of4bqmJE4xC8emJ67YimYm7pWHzj9c=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TbdYXix5; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TbdYXix5"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1DDD3C4CEF0;
	Wed, 10 Sep 2025 10:55:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757501757;
	bh=tsSBIpHdakcXHPvAGSyYjic7W9pbJfh7J6hCd32e9+g=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=TbdYXix57MI3tx9jghRLDuTu80ifiu+dJLF21A2ga2ld969DD6rfoCiQ/WyE4YpkN
	 E2z+ZbO3eYtX6tu+uO2+u9FyKP2FI+3F2qw0X6fDbhYnSEM3BSyNbAcjC7EYGv98Wc
	 ygueXUPeXdVZBJxOlRzranrLf7xxWNEm/TqRxM2bIhA7IHIqgb3bza6EwMleObMHh/
	 /Djl5iahx/Xa1oUG82OTH3jhFhDcRA3g6HSi6K0WwRgd91ukpBx4jdXwXxCJAbbOmH
	 8aFceCWUt0fUyELidoBiYZM3si+UJIq8XDaK80cR/dFMzTKhtk9x/wsDQN+Snl6IBh
	 AIgyzYpnzqEHg==
Date: Wed, 10 Sep 2025 06:55:55 -0400
From: Sasha Levin <sashal@kernel.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Jens Axboe <axboe@kernel.dk>, konstantin@linuxfoundation.org,
	csander@purestorage.com, io-uring@vger.kernel.org,
	torvalds@linux-foundation.org, workflows@vger.kernel.org
Subject: Re: [RFC] b4 dig: Add AI-powered email relationship discovery command
Message-ID: <aMFZO6g2L5YCKR_O@laps>
References: <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <20250909163214.3241191-1-sashal@kernel.org>
 <20250909172258.GH18349@pendragon.ideasonboard.com>
 <72dd17ad-5467-49d3-9f40-054b1bf875d5@kernel.dk>
 <aMB3_VgB4mwp-bzP@laps>
 <20250910101342.GD20904@pendragon.ideasonboard.com>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <20250910101342.GD20904@pendragon.ideasonboard.com>

On Wed, Sep 10, 2025 at 01:13:42PM +0300, Laurent Pinchart wrote:
>On Tue, Sep 09, 2025 at 02:54:53PM -0400, Sasha Levin wrote:
>> On Tue, Sep 09, 2025 at 11:26:19AM -0600, Jens Axboe wrote:
>> > On 9/9/25 11:22 AM, Laurent Pinchart wrote:
>> >> On Tue, Sep 09, 2025 at 12:32:14PM -0400, Sasha Levin wrote:
>> >>> Add a new 'b4 dig' subcommand that uses AI agents to discover related
>> >>> emails for a given message ID. This helps developers find all relevant
>> >>> context around patches including previous versions, bug reports, reviews,
>> >>> and related discussions.
>> >>
>> >> That really sounds like "if all you have is a hammer, everything looks
>> >> like a nail". The community has been working for multiple years to
>> >> improve discovery of relationships between patches and commits, with
>> >> great tools such are lore, lei and b4, and usage of commit IDs, patch
>> >> IDs and message IDs to link everything together. Those provide exact
>> >> results in a deterministic way, and consume a fraction of power of what
>> >> this patch would do. It would be very sad if this would be the direction
>> >> we decide to take.
>> >
>> > Fully agree, this kind of lazy "oh just waste billions of cycles and
>> > punt to some AI" bs is just kind of giving up on proper infrastructure
>> > to support maintainers and developers.
>>
>> This feels like a false choice: why force a pick between b4-dig-like tooling
>> and improving our infra? They can work together. As tagging and workflows
>> improve, those gains will flow into the tools anyway.
>>
>> It's like saying we should skip -rc releases because they mean we've given up
>> on bug free code.
>
>I really have trouble thinking this is a honest argument. We're
>discussing the topic in the context of a project where we reject
>thousands of patches all the time when they don't go in the right
>direction.
>
>Throwing an LLM at the problem is not just a major waste of power, it
>also hurts as it will shift the focus away from improving the
>deterministic tools we've been working on. Using an LLM here only
>benefits the companies that make money from those proprietary tools.

Really? Elsewhere in this thread I've already pointed out that something like
this is very helpful because having to review hundreds of commits for
backport/CVE assignment using our current scheme of Link: just pointing to the
original submission and not any discussions is a major pain and a time waste.

Both Linus and Greg echoed the same concern. Heck, this thread started because
Linus complained about how much of a human time waste our current scheme is.

So when presented with a real problem and a tool that can help mitigate it,
you're still choosing to attack because it's LLM based and you have something
personal against that.

Sorry, I'm done with this argument. Use it if you like, don't use it if you
don't.

-- 
Thanks,
Sasha

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64])
	(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 CDFF6311958;
	Wed, 10 Sep 2025 11:30:03 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.167.242.64
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757503805; cv=none; b=CmFUVYIt3AeFGVoHKzUXMSvVFPvYDmcBh7HnXgcRMe5H9RBFpDaDMRCMtEmEs1YO4wGqLH/blRn53nt6CDBhOvHONBKl0XdQYCTpG77H18MnectVq8G4GkAPimKgWYxvLSdmOKAPlCuP1thq7t98nHA6dQPCRoS2J9Mz/TxJsSU=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757503805; c=relaxed/simple;
	bh=dGGaE5gGnSoFmRFksPhIAkDqdqcyIncmyznWMwPQu9U=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=dtagy55wRm5m1xDYWbjQpYgNWOBfcE/p432tHnjEfM9cldqnyXufUOiEckzE2qr77yYrZmZA/gyoO6u7mmpduy/yAvT6QzJzdaeBUlRqem/86+Xn6PdwqRFUmwNNGhkHjeaT0SLqICR1xpPH1tC4J/sIpKAmPVD6HZdRrnF6V7c=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com; spf=pass smtp.mailfrom=ideasonboard.com; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b=huiukmA3; arc=none smtp.client-ip=213.167.242.64
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ideasonboard.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="huiukmA3"
Received: from pendragon.ideasonboard.com (81-175-209-231.bb.dnainternet.fi [81.175.209.231])
	by perceval.ideasonboard.com (Postfix) with UTF8SMTPSA id 8B5BF346;
	Wed, 10 Sep 2025 13:28:46 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;
	s=mail; t=1757503726;
	bh=dGGaE5gGnSoFmRFksPhIAkDqdqcyIncmyznWMwPQu9U=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=huiukmA3OrXdXQ8xXx+fJwmsFCZnfP1NL63xR3sVE39uXsRENm+HEGGviqsV6oz98
	 khRf0pZLzMVbR/VVPzNEVVjP7IU7boHpx1QTpN65SwaaP83seO71ZstP24597uRjfR
	 iEes1NaDtV8kAghJMlmNZNxhdBHbzktyF9VgvF7Y=
Date: Wed, 10 Sep 2025 14:29:37 +0300
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Sasha Levin <sashal@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>, konstantin@linuxfoundation.org,
	csander@purestorage.com, io-uring@vger.kernel.org,
	torvalds@linux-foundation.org, workflows@vger.kernel.org
Subject: Re: [RFC] b4 dig: Add AI-powered email relationship discovery command
Message-ID: <20250910112937.GE20904@pendragon.ideasonboard.com>
References: <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <20250909163214.3241191-1-sashal@kernel.org>
 <20250909172258.GH18349@pendragon.ideasonboard.com>
 <72dd17ad-5467-49d3-9f40-054b1bf875d5@kernel.dk>
 <aMB3_VgB4mwp-bzP@laps>
 <20250910101342.GD20904@pendragon.ideasonboard.com>
 <aMFZO6g2L5YCKR_O@laps>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <aMFZO6g2L5YCKR_O@laps>

On Wed, Sep 10, 2025 at 06:55:55AM -0400, Sasha Levin wrote:
> On Wed, Sep 10, 2025 at 01:13:42PM +0300, Laurent Pinchart wrote:
> > On Tue, Sep 09, 2025 at 02:54:53PM -0400, Sasha Levin wrote:
> >> On Tue, Sep 09, 2025 at 11:26:19AM -0600, Jens Axboe wrote:
> >>> On 9/9/25 11:22 AM, Laurent Pinchart wrote:
> >>>> On Tue, Sep 09, 2025 at 12:32:14PM -0400, Sasha Levin wrote:
> >>>>> Add a new 'b4 dig' subcommand that uses AI agents to discover related
> >>>>> emails for a given message ID. This helps developers find all relevant
> >>>>> context around patches including previous versions, bug reports, reviews,
> >>>>> and related discussions.
> >>>>
> >>>> That really sounds like "if all you have is a hammer, everything looks
> >>>> like a nail". The community has been working for multiple years to
> >>>> improve discovery of relationships between patches and commits, with
> >>>> great tools such are lore, lei and b4, and usage of commit IDs, patch
> >>>> IDs and message IDs to link everything together. Those provide exact
> >>>> results in a deterministic way, and consume a fraction of power of what
> >>>> this patch would do. It would be very sad if this would be the direction
> >>>> we decide to take.
> >>>
> >>> Fully agree, this kind of lazy "oh just waste billions of cycles and
> >>> punt to some AI" bs is just kind of giving up on proper infrastructure
> >>> to support maintainers and developers.
> >>
> >> This feels like a false choice: why force a pick between b4-dig-like tooling
> >> and improving our infra? They can work together. As tagging and workflows
> >> improve, those gains will flow into the tools anyway.
> >>
> >> It's like saying we should skip -rc releases because they mean we've given up
> >> on bug free code.
> >
> > I really have trouble thinking this is a honest argument. We're
> > discussing the topic in the context of a project where we reject
> > thousands of patches all the time when they don't go in the right
> > direction.
> >
> > Throwing an LLM at the problem is not just a major waste of power, it
> > also hurts as it will shift the focus away from improving the
> > deterministic tools we've been working on. Using an LLM here only
> > benefits the companies that make money from those proprietary tools.
> 
> Really? Elsewhere in this thread I've already pointed out that something like
> this is very helpful because having to review hundreds of commits for
> backport/CVE assignment using our current scheme of Link: just pointing to the
> original submission and not any discussions is a major pain and a time waste.

That's debatable at best, I've stopped counting the number of developers
who are unhappy with the over-aggressive backport policy, and how LLMs
pick commits for backport that have no reason to be backported.

Don't get me wrong, I wouldn't want to be responsible for maintaining
stable kernels given the volume of commits. It's a never-ending,
thankless job. Still, claiming that LLMs solve the problem doesn't seem
true to me, they merely provide some sort of automation to allow us to
claim the problem has been addressed. It's closer to theatre than
engineering.

> Both Linus and Greg echoed the same concern. Heck, this thread started because
> Linus complained about how much of a human time waste our current scheme is.
> 
> So when presented with a real problem and a tool that can help mitigate it,
> you're still choosing to attack because it's LLM based and you have something
> personal against that.

I've long had something personal about using the wrong tool for a job
:-) That has very little chance of changing.

> Sorry, I'm done with this argument. Use it if you like, don't use it if you
> don't.

-- 
Regards,

Laurent Pinchart

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 09B75276051;
	Wed, 10 Sep 2025 12:19:53 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757506794; cv=none; b=ICSxg5fmdAeXIIjj7gXkAF2a0e7O+G73paiCYJMfRqs5Ry2rCVRzHmw0nOW6ClbDFI3gD7TdGcQ+50ek+aWagQlm9BN09HgE4Iwu890C5VGFBZAjjqZuFoVnfs1BnGMj6Wfh9twrRK359+nHj/JxtKrNgVwUYOMWoOhhdQo46HM=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757506794; c=relaxed/simple;
	bh=m2lIjYXiBT84ffpnStHjjrdVAEucnB8L201CVsqOcpQ=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=nyizJ3DP5n4pt45wL61/PGnRJIjtzBpygAVkSTI2kwS3gc3nHHjBT6nftDXe3LCBl1cQf/P/aRQHwB3X4PnIIlUqUuOzYiIT+rAaVq88Cdvh19pnLTI7NyZVGeaaE1kOCy28blLAwko7r2GzgccHIUhehkTwA0fTN6Q0AJIDUag=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=P1fwqZZb; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="P1fwqZZb"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A22EBC4CEF0;
	Wed, 10 Sep 2025 12:19:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757506793;
	bh=m2lIjYXiBT84ffpnStHjjrdVAEucnB8L201CVsqOcpQ=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=P1fwqZZblkaa++z0wFf2WXhuT6pgQBQ22dAKJ2qpqVgL6AxKY9XofdpsYdjbhCQJW
	 uTdSCDeKrlAyStGzYZNNwMB3PBPVpvW019gqa4t3tWw42ZaTtqTKxTYHYVYyLVs3OA
	 euImLd9U2hXfdgSysMva40iyuZn5smrLakqk9XJW6TEY7/GwQKeIe6XgRUJBBuYTmI
	 alazqy3BYePzNnpMRNsXstYllJVq6xUDvsO8dWQ1JYwIE/dF1MuslVqUFEve+fUEgn
	 Ro1ku1TkY5izDiaMpr++NyIYizAtaJqUCkbFmhuBuMwA5If4hUyJ6RGWPFjMT69OW3
	 cOZa5LQELDK3w==
Date: Wed, 10 Sep 2025 13:19:48 +0100
From: Mark Brown <broonie@kernel.org>
To: dan.j.williams@intel.com
Cc: Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>, Vlastimil Babka <vbabka@suse.cz>,
	Jakub Kicinski <kuba@kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Caleb Sander Mateos <csander@purestorage.com>,
	io-uring <io-uring@vger.kernel.org>, workflows@vger.kernel.org
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for
 6.17-rc5)
Message-ID: <cc99e802-ffa1-4665-aed3-e3ee965a71b0@sirena.org.uk>
References: <92dc8570-84a2-4015-9c7a-6e7da784869a@kernel.dk>
 <20250909-green-oriole-of-speed-85cd6d@lemur>
 <497c9c10-3309-49b9-8d4f-ff0bc34df4e5@suse.cz>
 <be98399d-3886-496e-9cf4-5ec909124418@kernel.dk>
 <CAHk-=whP2zoFm+-EmgQ69-00cxM5jgoEGWyAYVQ8bQYFbb2j=Q@mail.gmail.com>
 <af29e72b-ade6-4549-b264-af31a3128cf1@sirena.org.uk>
 <CAHk-=wiN+8EUoik4UeAJ-HPSU7hczQP+8+_uP3vtAy_=YfJ9PQ@mail.gmail.com>
 <CAHk-=wh2F5EPJWhiEeW=Ft0rx9HFcZj2cWnNGh_OuR0kdBm8UA@mail.gmail.com>
 <20250909-impetuous-swine-of-chaos-2aa9af@meerkat>
 <68c0d07372c8d_4224d100dc@dwillia2-mobl4.notmuch>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="3RrWNWWD4p39M8rR"
Content-Disposition: inline
In-Reply-To: <68c0d07372c8d_4224d100dc@dwillia2-mobl4.notmuch>
X-Cookie: I think my career is ruined!


--3RrWNWWD4p39M8rR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Sep 09, 2025 at 06:12:19PM -0700, dan.j.williams@intel.com wrote:
> Konstantin Ryabitsev wrote:

> > We can't control how the patches are generated by submitters. If someone
> > generates and sends them with --histogram, this won't work. Here's an example
> > right from your tree:

> Is this a matter of teach git send-email to generate a header, e.g.
> "X-Patch-ID:", for a given stable diff format convention? That lets
> submitters use any diff format they want, but the X-Patch-ID: is
> constant. Then "git show $diff_opts_convention $commit" becomes more
> reliable over time.

We can't rely on people using git send-email at all, and they might be
using an old version (eg, from their distro) even when thy do.

> It still does not help the problem of maintainers massaging patches on
> their way upstream, but patch.msgid.link does not help that either
> because that Link: is not the patch that was merged. So if you care
> about automated tooling being able to query lore for commits, the

That's not really what people are using these links for - if you have
the commit you don't need to go to the mailing list archive to get it.
You're more likely to be using them to find the relevant discussion, see
who was involved and possibly send some kind of followup (eg, to report
a regression in my case).  A link tag, especially one with a well
defined domain for the links, works fine in this sort of application
since it's pointing at the last point the thing was on the list
regardless of how poorly what's made it into git corresponds to what was
posted.

--3RrWNWWD4p39M8rR
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmjBbOQACgkQJNaLcl1U
h9Bm+gf9Etuh1V61zc0Tmm1qR4YKDzschf9Zc1N2x+BidviOFp64DuGJahcCrXqb
CAhcMafY6ak0TK+EzQJtAgo6jKdS72i0lHiZ3KVFT2IofkOsTf3yxRc+qBZ6GjDb
A56eICFOkJjYLJqnLlvjhlR+Hl/GFmUEUA6DIJ3UgUYNpqWoGb8bo9my7B7D8ALy
BvPXA8CdbeQYZA85UJvg1Y3Dw8yCPragaEN9l5WRxWOgxMb0xhu/NgkJx/s6o0+R
aat8vQloZDlNNEy40gLzdf7lLd5Nb0rmcv/5566ubFVdQfTD2xFW0/XlCJdMpSps
YBH5va4rvmLCZpxzTlrammurHkHgxg==
=rI70
-----END PGP SIGNATURE-----

--3RrWNWWD4p39M8rR--

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 AC0ED1494CC;
	Wed, 10 Sep 2025 13:38:11 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757511491; cv=none; b=LclHJiAAIVi4pdaUhXQ7uIcUkL9PzulumGUEkA853trsk0h1BchSaef5LnLGfCwJ6lYHLfZJ9KoikGk5SXZcndSbBzQezHH/i8VkZCxzhu9xMPeNNwROa9Xc9yO8TcD8STWQSkC2XfcjCLeZ0mdL9YdelO2gB+Jb8tqr4Q0rRPM=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757511491; c=relaxed/simple;
	bh=OLQSadqn5sk7Ywbb2Knr3epvYKMxJSzK4qTU8lUhQns=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=OfvxXjsFcKWWwriAn+Uecc8bXS+EL++FRC19PXlviMHscbhfUy6F+S+Qpzfnxuc7qbXF5Tj7+f0TEps6oFAg7kSlE1pKchbsvIsZuwMrzQXicIIm3pLBDX0/oRap1/Pmil6LE28snhAW3IaSLqZlfzokJi7IZYVNFjGCwW12bzA=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=qKsGywPG; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="qKsGywPG"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1115DC4CEF0;
	Wed, 10 Sep 2025 13:38:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1757511491;
	bh=OLQSadqn5sk7Ywbb2Knr3epvYKMxJSzK4qTU8lUhQns=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=qKsGywPGCBoq7Z0SnP6tkDmpnlZkhXSTMKKH1ZAiPLFAXwMKe07C4m3RngBFq1t1M
	 QDB70Q1Qim8E5IcBPUr7KZJFuyNTuO1At6m/aUst7wVSVvQTpJlxo3sqGLXFiYkcLx
	 ECKJMgZJ2DpimqURtoGP3pGKins8aWGhAagolpmY=
Date: Wed, 10 Sep 2025 09:38:09 -0400
From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Sasha Levin <sashal@kernel.org>, axboe@kernel.dk, 
	csander@purestorage.com, io-uring@vger.kernel.org, torvalds@linux-foundation.org, 
	workflows@vger.kernel.org
Subject: Re: [RFC] b4 dig: Add AI-powered email relationship discovery command
Message-ID: <20250910-augmented-ludicrous-tortoise-0a53bd@lemur>
References: <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <20250909163214.3241191-1-sashal@kernel.org>
 <20250909172258.GH18349@pendragon.ideasonboard.com>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250909172258.GH18349@pendragon.ideasonboard.com>

On Tue, Sep 09, 2025 at 08:22:58PM +0300, Laurent Pinchart wrote:
> On Tue, Sep 09, 2025 at 12:32:14PM -0400, Sasha Levin wrote:
> > Add a new 'b4 dig' subcommand that uses AI agents to discover related
> > emails for a given message ID. This helps developers find all relevant
> > context around patches including previous versions, bug reports, reviews,
> > and related discussions.
> 
> That really sounds like "if all you have is a hammer, everything looks
> like a nail". The community has been working for multiple years to
> improve discovery of relationships between patches and commits, with
> great tools such are lore, lei and b4, and usage of commit IDs, patch
> IDs and message IDs to link everything together. Those provide exact
> results in a deterministic way, and consume a fraction of power of what
> this patch would do. It would be very sad if this would be the direction
> we decide to take.

I don't want to go too far down the "wasting resources path," because,
honestly, a kid playing videogames for a weekend will waste more power than a
maintainer submitting a couple of threads for analysis.

I've already worked on plugging in LLMs into summarization, so I'm not alien
or opposed to this approach. I'd like to make this available to maintainers
who find it useful, and completely out of the way for those maintainers who
hate the whole idea. :)

Best wishes,
-K

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from fout-a8-smtp.messagingengine.com (fout-a8-smtp.messagingengine.com [103.168.172.151])
	(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 D5FDB26FA77;
	Wed, 10 Sep 2025 14:04:08 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.151
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757513051; cv=none; b=TiPGNG03qMw2cEC5oifsRQvAxzvri6NioKLiyMX2X4YVU28p2dPCjZjM7k0kpiPsKqK9R5uaHisE743UpqvxJceuAFgJ3ClPuE9kT8Ha1k7RnyTq76CP7hoxPs0cD90EVZQ6iLMLFZDdhpBSc36P3ptWt4IM4uC2CkQZcsPxKoI=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757513051; c=relaxed/simple;
	bh=uUFAoktO277xXwHHnswYPQKvbx+QmoiX+wDMEuUdm/g=;
	h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References:
	 Subject:Content-Type; b=s0W+Yyw1d/Q/SCwybxuv8nY3SKyq/rVN5DTuPopJMnjN0L0fI+ZU6tHne2AJsNripfjfTWxJp/CbOFJJDIxts3stV9baivUugeco3l3Chp45+pGpAy3jEN7iBDyLFDlWCvUvDe5ccKHA3OX/O4cIW5Lj1e3ToFlRHcTebdZ6v50=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=donacou.ch; spf=pass smtp.mailfrom=donacou.ch; dkim=pass (2048-bit key) header.d=donacou.ch header.i=@donacou.ch header.b=l9tlwE/C; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=dMrrQkSs; arc=none smtp.client-ip=103.168.172.151
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=donacou.ch
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=donacou.ch
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=donacou.ch header.i=@donacou.ch header.b="l9tlwE/C";
	dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="dMrrQkSs"
Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46])
	by mailfout.phl.internal (Postfix) with ESMTP id E660CEC044E;
	Wed, 10 Sep 2025 10:04:07 -0400 (EDT)
Received: from phl-imap-15 ([10.202.2.104])
  by phl-compute-06.internal (MEProxy); Wed, 10 Sep 2025 10:04:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=donacou.ch; h=cc
	:cc:content-transfer-encoding:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm3; t=1757513047;
	 x=1757599447; bh=3Nuaa+FoSrAxipH9n0l4tF6X+2obMMAQMJqsmRgL2c8=; b=
	l9tlwE/C9WUogEbHgyOlQIf0QymIUkvJyMxRMPitRzg/FkZD9P29HGA/jBJJaT5Z
	hIMQ8XX8s1/UKj109XkhUxpmTnkoMFpBr4OgCBgEYIaGbn/1Ixmt542YXlla65Gt
	xEnGHwyQ7VRfLRcHHN1/xnuLZvPdq+n0gvmzE53rYXZCJO56vcIX1BWNodzVl94O
	C5Lqr+T2eHOm7g6fBfdScHByTEo9qBrZf+KSv/w5vGo0EMDOZDWrPtG9pNduokSm
	VqdXt/WrUN1uQ4+GKOfAfA/WM9+C1yXzTruyDT16lHh5R0Rl4r/RzZH/I6qdmf3I
	msozoe4B0v/vQ6zLp3fjCQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1757513047; x=
	1757599447; bh=3Nuaa+FoSrAxipH9n0l4tF6X+2obMMAQMJqsmRgL2c8=; b=d
	MrrQkSsXutiVu49JEqI6vnAFpKvT8A6QNqvfM9kPFvVCVSSaaPAPYQnJclPCpGsp
	SdjQuOvrJ/jb6SE3iGQ4qBkWgu4EbQbkkCrWXSsYvMMV8+Ko2YVylXT335au1vQI
	craNWyKZOwCYjeGMqIdt1Y+A+ElKK+kazHb1c30gkDJMl9GOeFg325dDwXZxL6xJ
	w1/xsTIY3pYom5hE5rWbqCNHtwko+lHJTGGVafRclV1f+jDlUvrhCnhXJH7S7xYh
	YfUB02q3CTpJgGgX99GLroYIaP+zc8U+Ubkoc/zsThr4ISyBuk8WpVSAjGCGbXtf
	sy+5NIajuS0UNRQ+AxDtg==
X-ME-Sender: <xms:V4XBaG8fEFhl1flxgvC3qg_bRGSEPGU8e5cZuM8WiH3DJMUMLhJAmw>
    <xme:V4XBaGs4ZX-O_x2EggLhVA-fohGgdBDE51IQviKCsOO3p13ZbVo5VXlIca3K7p6Uv
    Uc4YqMNU0y0dah2>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvfeegkecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
    ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
    hrpefoggffhffvvefkjghfufgtgfesthejredtredttdenucfhrhhomhepfdetnhgurhgv
    ficuffhonhgrqdevohhutghhfdcuoegrnhgurhgvfiesughonhgrtghouhdrtghhqeenuc
    ggtffrrghtthgvrhhnpeejteduiedtfffhhfffgeevvdefheduheegjeduteffteduvdfh
    jeegffduledvieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh
    hrohhmpegrnhgurhgvfiesughonhgrtghouhdrtghhpdhnsggprhgtphhtthhopeekpdhm
    ohguvgepshhmthhpohhuthdprhgtphhtthhopehlrghurhgvnhhtrdhpihhntghhrghrth
    esihguvggrshhonhgsohgrrhgurdgtohhmpdhrtghpthhtoheprgigsghovgeskhgvrhhn
    vghlrdgukhdprhgtphhtthhopehsrghshhgrlheskhgvrhhnvghlrdhorhhgpdhrtghpth
    htohepthhorhhvrghlughssehlihhnuhigqdhfohhunhgurghtihhonhdrohhrghdprhgt
    phhtthhopehkohhnshhtrghnthhinheslhhinhhugihfohhunhgurghtihhonhdrohhrgh
    dprhgtphhtthhopegtshgrnhguvghrsehpuhhrvghsthhorhgrghgvrdgtohhmpdhrtghp
    thhtohepihhoqdhurhhinhhgsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoh
    epfihorhhkfhhlohifshesvhhgvghrrdhkvghrnhgvlhdrohhrgh
X-ME-Proxy: <xmx:V4XBaMJrumzWH892lXeHhEz1bgXykBCz7cc4cjp1iFta4-7ByKla3Q>
    <xmx:V4XBaC5-y92JbCH0zV4XUAn-VIl5bgNzyHLGZddtUdQWP01TJRbP3g>
    <xmx:V4XBaOftHaxM-2tiHzDrJju2TOWDpwHj-4TGhCXPGPbgVrBhJji-UA>
    <xmx:V4XBaFGqjVZBWIpW557ZR195MEUdh9izNqns44KGWhDb_hPL2G2HzQ>
    <xmx:V4XBaPQyIRrl_KVyuOwUGZpIDcjEIsafSbI9rSsAdoIjChsta8nMA8cz>
Feedback-ID: i594043eb:Fastmail
Received: by mailuser.phl.internal (Postfix, from userid 501)
	id 41D8A78026F; Wed, 10 Sep 2025 10:04:07 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-ThreadId: A6d2yW3kTJ_V
Date: Wed, 10 Sep 2025 10:03:40 -0400
From: "Andrew Dona-Couch" <andrew@donacou.ch>
To: "Konstantin Ryabitsev" <konstantin@linuxfoundation.org>,
 "Laurent Pinchart" <laurent.pinchart@ideasonboard.com>
Cc: "Sasha Levin" <sashal@kernel.org>, axboe@kernel.dk,
 csander@purestorage.com, "io_uring Mailing List" <io-uring@vger.kernel.org>,
 torvalds@linux-foundation.org, workflows@vger.kernel.org
Message-Id: <ce7536b4-e83c-4a0f-a46a-0bb0c8eb3610@app.fastmail.com>
In-Reply-To: <20250910-augmented-ludicrous-tortoise-0a53bd@lemur>
References: <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <20250909163214.3241191-1-sashal@kernel.org>
 <20250909172258.GH18349@pendragon.ideasonboard.com>
 <20250910-augmented-ludicrous-tortoise-0a53bd@lemur>
Subject: Re: [RFC] b4 dig: Add AI-powered email relationship discovery command
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

What a remarkable discussion!  The arguments being made lay bare an important difference in perspective.

> you're still choosing to attack because it's LLM based and you have something
> personal against that.

This argument seems an utter abrogation of an engineer's core responsibility to understand the tools they use.  The concerns raised against LLMs here were specific and technical, were they not?

> I don't want to go too far down the "wasting resources path," because,
> honestly, a kid playing videogames for a weekend will waste more power than a
> maintainer submitting a couple of threads for analysis.

Quite disingenuous to treat the marginal cost of a single search as if it accounted for the true cost to society of making the product available.

I appreciate the careful consideration of maintainers here who work to keep the focus of development on real humans and a thoughtful and deliberative processes.

Thanks,
Andrew




-- 
We all do better when we all do better.  -Paul Wellstone

On Wed, Sep 10, 2025, at 09:38, Konstantin Ryabitsev wrote:
> On Tue, Sep 09, 2025 at 08:22:58PM +0300, Laurent Pinchart wrote:
>> On Tue, Sep 09, 2025 at 12:32:14PM -0400, Sasha Levin wrote:
>> > Add a new 'b4 dig' subcommand that uses AI agents to discover related
>> > emails for a given message ID. This helps developers find all relevant
>> > context around patches including previous versions, bug reports, reviews,
>> > and related discussions.
>> 
>> That really sounds like "if all you have is a hammer, everything looks
>> like a nail". The community has been working for multiple years to
>> improve discovery of relationships between patches and commits, with
>> great tools such are lore, lei and b4, and usage of commit IDs, patch
>> IDs and message IDs to link everything together. Those provide exact
>> results in a deterministic way, and consume a fraction of power of what
>> this patch would do. It would be very sad if this would be the direction
>> we decide to take.
>
> I don't want to go too far down the "wasting resources path," because,
> honestly, a kid playing videogames for a weekend will waste more power than a
> maintainer submitting a couple of threads for analysis.
>
> I've already worked on plugging in LLMs into summarization, so I'm not alien
> or opposed to this approach. I'd like to make this available to maintainers
> who find it useful, and completely out of the way for those maintainers who
> hate the whole idea. :)
>
> Best wishes,
> -K

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from sender4-pp-f112.zoho.com (sender4-pp-f112.zoho.com [136.143.188.112])
	(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 928E11E1DE9;
	Thu, 11 Sep 2025 14:48:17 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=136.143.188.112
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757602102; cv=pass; b=BmRHtaqnxJ50ioT/+g/VeqqHwFcRPEPjWW48jZP7oPvp3ZT7cPgAJdGv+LLkZyG/rTitDNZW3XOi5i11blVNisX2Txvw0lDxhxqBmjgqoKJCn2UJ1RZJbR9y9K4RJ+mFsis7DvAlB9RQCcRV4rxO6GSZyLStxxP9r9A37u1Acr8=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757602102; c=relaxed/simple;
	bh=DaBAC8YoPwWLXp926blX2bKwDqEooN4nGpFi2hcHB3k=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version:Content-Type; b=acKvJ/+WHMgsb/WS/wr/LIU3tZwL8UiBXGxiV3eyY/CT+Vs9S0na6IhzxljIq2IWlHpGFAnaIqPDu0AOyYzo/lF2GRDDbylA0hFW0W5MKx7DjZFcfxcAJ0R8+Xa8+ZiemUgJzbJwvm+sW0EwMXJPal8QDsmqevfw2lmQq/NHytI=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (1024-bit key) header.d=collabora.com header.i=nicolas.frattaroli@collabora.com header.b=Eh9OkEzj; arc=pass smtp.client-ip=136.143.188.112
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=collabora.com header.i=nicolas.frattaroli@collabora.com header.b="Eh9OkEzj"
ARC-Seal: i=1; a=rsa-sha256; t=1757602089; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=LyfLziWbMGRoNk6Zp0ZAoUB0mHztscOvVrIAUQ9mszEG2WNIf9/ZKb0CePmkwhBgn9LUKJHqbPlZED6ROAdIETcSaVTdPu+1djCczemXKj6Iw+BwpCkZVS79iCKTkOAJ+vIRGQ7Lv3+z0xww1mEsAsIFiYPFPGlqrF0b7KG4nJk=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1757602089; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=F7KiB8G7wL7sZPbDJGE/AKkJSefd9KC8FPd1XkRckik=; 
	b=KAi2zTI3ZHqthufWS/0pdefAn+/e/a5MF1B4xrvC1xD2OhGMO11uyrZnVzS1i8YsjgZuzj8BaaRAyqF62G53n3zZQLK/zbVFTCakNFNNRD+EA7T9eRBxudgnDn49AStXkETwLb5tV1xIFRINj5IeOWhThDWm6cqtVAaT3zAddmg=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=collabora.com;
	spf=pass  smtp.mailfrom=nicolas.frattaroli@collabora.com;
	dmarc=pass header.from=<nicolas.frattaroli@collabora.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1757602089;
	s=zohomail; d=collabora.com; i=nicolas.frattaroli@collabora.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-ID:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Reply-To;
	bh=F7KiB8G7wL7sZPbDJGE/AKkJSefd9KC8FPd1XkRckik=;
	b=Eh9OkEzj0su3H6CmNWfogmpuhtGzVStA6pzDX9mRm1TjudKpZAPtTmrYkorJoTpn
	wO+SarH1tdq+quNBdZeFomu1sYNdpTdNtJjbSqM6f/rlpyOPfENj2J+Le1Q1aBOO57u
	P1mTQPsJsndLTDJmJ5XYpmxYYvtnVcHw0LcRkxbA=
Received: by mx.zohomail.com with SMTPS id 1757602086814201.2829005224047;
	Thu, 11 Sep 2025 07:48:06 -0700 (PDT)
From: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
To: konstantin@linuxfoundation.org, Sasha Levin <sashal@kernel.org>
Cc: axboe@kernel.dk, csander@purestorage.com, io-uring@vger.kernel.org,
 torvalds@linux-foundation.org, workflows@vger.kernel.org,
 Sasha Levin <sashal@kernel.org>
Subject: Re: [RFC] b4 dig: Add AI-powered email relationship discovery command
Date: Thu, 11 Sep 2025 16:48:03 +0200
Message-ID: <4764751.e9J7NaK4W3@workhorse>
In-Reply-To: <20250909163214.3241191-1-sashal@kernel.org>
References:
 <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <20250909163214.3241191-1-sashal@kernel.org>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

On Tuesday, 9 September 2025 18:32:14 Central European Summer Time Sasha Le=
vin wrote:
> Add a new 'b4 dig' subcommand that uses AI agents to discover related
> emails for a given message ID. This helps developers find all relevant
> context around patches including previous versions, bug reports, reviews,
> and related discussions.
>=20
> The command:
> - Takes a message ID and constructs a detailed prompt about email relatio=
nships
> - Calls a configured AI agent script to analyze and find related messages
> - Downloads all related threads from lore.kernel.org
> - Combines them into a single mbox file for easy review
>=20
> Key features:
> - Outputs a simplified summary showing only relationships and reasons
> - Creates a combined mbox with all related threads (deduped)
> - Provides detailed guidance to AI agents about kernel workflow patterns
>=20
> Configuration:
> The AI agent script is configured via:
>   -c AGENT=3D/path/to/agent.sh  (command line)
>   dig-agent: /path/to/agent.sh (config file)
>=20
> The agent script receives a prompt file and should return JSON with
> related message IDs and their relationships.
>=20
> Example usage:
>=20
> $ b4 -c AGENT=3Dagent.sh dig 20250909142722.101790-1-harry.yoo@oracle.com
> Analyzing message: 20250909142722.101790-1-harry.yoo@oracle.com
> Fetching original message...
> Looking up https://lore.kernel.org/20250909142722.101790-1-harry.yoo@orac=
le.com
> Grabbing thread from lore.kernel.org/all/20250909142722.101790-1-harry.yo=
o@oracle.com/t.mbox.gz
> Subject: [PATCH V3 6.6.y] mm: introduce and use {pgd,p4d}_populate_kernel=
()
> From: Harry Yoo <harry.yoo@oracle.com>
> Constructing agent prompt...
> Calling AI agent: agent.sh
> Calling agent: agent.sh /tmp/tmpz1oja9_5.txt
> Parsing agent response...
> Found 17 related messages:
>=20
> Related Messages Summary:
> ------------------------------------------------------------
> [PARENT] Greg KH's stable tree failure notification that initiated this 6=
=2E6.y backport request
> [V1] V1 of the 6.6.y backport patch
> [V2] V2 of the 6.6.y backport patch
> [RELATED] Same patch backported to 5.15.y stable branch
> [RELATED] Greg KH's stable tree failure notification for 5.15.y branch
> [RELATED] Same patch backported to 6.1.y stable branch
> [COVER] V5 mainline patch series cover letter that was originally merged
> [RELATED] V5 mainline patch 1/3: move page table sync declarations
> [RELATED] V5 mainline patch 2/3: the original populate_kernel patch that'=
s being backported
> [RELATED] V5 mainline patch 3/3: x86 ARCH_PAGE_TABLE_SYNC_MASK definition
> [RELATED] RFC V1 cover letter - earliest version of this patch series
> [RELATED] RFC V1 patch 1/3 - first introduction of populate_kernel helpers
> [RELATED] RFC V1 patch 2/3 - x86/mm definitions
> [RELATED] RFC V1 patch 3/3 - convert to _kernel variant
> [RELATED] Baoquan He's V3 patch touching same file (mm/kasan/init.c)
> [RELATED] Baoquan He's V2 patch touching same file (mm/kasan/init.c)
> [RELATED] Baoquan He's V1 patch touching same file (mm/kasan/init.c)
> ------------------------------------------------------------
>=20
> The resulting mbox would look like this:
>=20
>    1 O   Jul 09 Harry Yoo       ( 102) [RFC V1 PATCH mm-hotfixes 0/3] mm,=
 arch: A more robust approach to sync top level kernel page tables
>    2 O   Jul 09 Harry Yoo       ( 143) =E2=94=9C=E2=94=80>[RFC V1 PATCH m=
m-hotfixes 1/3] mm: introduce and use {pgd,p4d}_populate_kernel()
>    3 O   Jul 11 David Hildenbra (  33) =E2=94=82 =E2=94=94=E2=94=80>
>    4 O   Jul 13 Harry Yoo       (  56) =E2=94=82   =E2=94=94=E2=94=80>
>    5 O   Jul 13 Mike Rapoport   (  67) =E2=94=82     =E2=94=94=E2=94=80>
>    6 O   Jul 14 Harry Yoo       (  46) =E2=94=82       =E2=94=94=E2=94=80>
>    7 O   Jul 15 Harry Yoo       (  65) =E2=94=82         =E2=94=94=E2=94=
=80>
>    8 O   Jul 09 Harry Yoo       ( 246) =E2=94=9C=E2=94=80>[RFC V1 PATCH m=
m-hotfixes 2/3] x86/mm: define p*d_populate_kernel() and top-level page tab=
le sync
>    9 O   Jul 09 Andrew Morton   (  12) =E2=94=82 =E2=94=9C=E2=94=80>
>   10 O   Jul 10 Harry Yoo       (  23) =E2=94=82 =E2=94=82 =E2=94=94=E2=
=94=80>
>   11 O   Jul 11 Harry Yoo       (  34) =E2=94=82 =E2=94=82   =E2=94=94=E2=
=94=80>
>   12 O   Jul 11 Harry Yoo       (  35) =E2=94=82 =E2=94=82     =E2=94=94=
=E2=94=80>
>   13 O   Jul 10 kernel test rob (  79) =E2=94=82 =E2=94=94=E2=94=80>
>   14 O   Jul 09 Harry Yoo       ( 300) =E2=94=9C=E2=94=80>[RFC V1 PATCH m=
m-hotfixes 3/3] x86/mm: convert {pgd,p4d}_populate{,_init} to _kernel varia=
nt
>   15 O   Jul 10 kernel test rob (  80) =E2=94=82 =E2=94=94=E2=94=80>
>   16 O   Jul 09 Harry Yoo       (  31) =E2=94=94=E2=94=80>Re: [RFC V1 PAT=
CH mm-hotfixes 0/3] mm, arch: A more robust approach to sync top level kern=
el page tables
>   17 O   Aug 18 Harry Yoo       ( 262) [PATCH V5 mm-hotfixes 0/3] mm, x86=
: fix crash due to missing page table sync and make it harder to miss
>   18 O   Aug 18 Harry Yoo       (  72) =E2=94=9C=E2=94=80>[PATCH V5 mm-ho=
tfixes 1/3] mm: move page table sync declarations to linux/pgtable.h
>   19 O   Aug 18 David Hildenbra (  20) =E2=94=82 =E2=94=94=E2=94=80>
>   20 O   Aug 18 Harry Yoo       ( 239) =E2=94=9C=E2=94=80>[PATCH V5 mm-ho=
tfixes 2/3] mm: introduce and use {pgd,p4d}_populate_kernel()
>   21 O   Aug 18 David Hildenbra (  60) =E2=94=82 =E2=94=9C=E2=94=80>
>   22 O   Aug 18 kernel test rob ( 150) =E2=94=82 =E2=94=9C=E2=94=80>
>   23 O   Aug 18 Harry Yoo       ( 161) =E2=94=82 =E2=94=82 =E2=94=94=E2=
=94=80>
>   24 O   Aug 21 Harry Yoo       (  85) =E2=94=82 =E2=94=9C=E2=94=80>[PATC=
H] mm: fix KASAN build error due to p*d_populate_kernel()
>   25 O   Aug 21 kernel test rob (  18) =E2=94=82 =E2=94=82 =E2=94=9C=E2=
=94=80>
>   26 O   Aug 21 Lorenzo Stoakes ( 100) =E2=94=82 =E2=94=82 =E2=94=9C=E2=
=94=80>
>   27 O   Aug 21 Harry Yoo       (  62) =E2=94=82 =E2=94=82 =E2=94=82 =E2=
=94=94=E2=94=80>
>   28 O   Aug 21 Lorenzo Stoakes (  18) =E2=94=82 =E2=94=82 =E2=94=82   =
=E2=94=94=E2=94=80>
>   29 O   Aug 21 Harry Yoo       (  90) =E2=94=82 =E2=94=82 =E2=94=94=E2=
=94=80>[PATCH v2] mm: fix KASAN build error due to p*d_populate_kernel()
>   30 O   Aug 21 kernel test rob (  18) =E2=94=82 =E2=94=82   =E2=94=9C=E2=
=94=80>
>   31 O   Aug 21 Dave Hansen     (  24) =E2=94=82 =E2=94=82   =E2=94=94=E2=
=94=80>
>   32 O   Aug 22 Harry Yoo       (  56) =E2=94=82 =E2=94=82     =E2=94=94=
=E2=94=80>
>   33 O   Aug 22 Andrey Ryabinin (  91) =E2=94=82 =E2=94=82       =E2=94=
=9C=E2=94=80>
>   34 O   Aug 27 Harry Yoo       (  98) =E2=94=82 =E2=94=82       =E2=94=
=82 =E2=94=94=E2=94=80>
>   35 O   Aug 22 Dave Hansen     (  63) =E2=94=82 =E2=94=82       =E2=94=
=94=E2=94=80>
>   36 O   Aug 25 Andrey Ryabinin (  72) =E2=94=82 =E2=94=82         =E2=94=
=94=E2=94=80>
>   37 O   Aug 22 Harry Yoo       ( 103) =E2=94=82 =E2=94=94=E2=94=80>[PATC=
H v3] mm: fix KASAN build error due to p*d_populate_kernel()
>   38 O   Aug 18 Harry Yoo       ( 113) =E2=94=9C=E2=94=80>[PATCH V5 mm-ho=
tfixes 3/3] x86/mm/64: define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kerne=
l_mappings()
>   39 O   Aug 18 David Hildenbra (  72) =E2=94=82 =E2=94=94=E2=94=80>
>   40 O   Aug 18 David Hildenbra (  15) =E2=94=94=E2=94=80>Re: [PATCH V5 m=
m-hotfixes 0/3] mm, x86: fix crash due to missing page table sync and make =
it harder to miss
>   41 O   Aug 18 Harry Yoo       ( 277) [PATCH] mm: introduce and use {pgd=
,p4d}_populate_kernel()
>   42 O   Aug 18 Harry Yoo       ( 277) [PATCH] mm: introduce and use {pgd=
,p4d}_populate_kernel()
>   43 O   Aug 18 Harry Yoo       ( 277) [PATCH] mm: introduce and use {pgd=
,p4d}_populate_kernel()
>   44 O   Sep 06 gregkh@linuxfou (  24) FAILED: patch "[PATCH] mm: introdu=
ce and use {pgd,p4d}_populate_kernel()" failed to apply to 6.6-stable tree
>   45 O   Sep 08 Harry Yoo       ( 303) =E2=94=9C=E2=94=80>[PATCH 6.6.y] m=
m: introduce and use {pgd,p4d}_populate_kernel()
>   46 O   Sep 09 Harry Yoo       ( 291) =E2=94=9C=E2=94=80>[PATCH V2 6.6.y=
] mm: introduce and use {pgd,p4d}_populate_kernel()
>   47 O   Sep 09 Harry Yoo       ( 293) =E2=94=94=E2=94=80>[PATCH V3 6.6.y=
] mm: introduce and use {pgd,p4d}_populate_kernel()
>   48 O   Sep 06 gregkh@linuxfou (  24) FAILED: patch "[PATCH] mm: introdu=
ce and use {pgd,p4d}_populate_kernel()" failed to apply to 6.1-stable tree
>   49 O   Sep 08 Harry Yoo       ( 303) =E2=94=9C=E2=94=80>[PATCH 6.1.y] m=
m: introduce and use {pgd,p4d}_populate_kernel()
>   50 O   Sep 09 Harry Yoo       ( 291) =E2=94=9C=E2=94=80>[PATCH V2 6.1.y=
] mm: introduce and use {pgd,p4d}_populate_kernel()
>   51 O   Sep 09 Harry Yoo       ( 293) =E2=94=94=E2=94=80>[PATCH V3 6.1.y=
] mm: introduce and use {pgd,p4d}_populate_kernel()
>   52 O   Sep 06 gregkh@linuxfou (  24) FAILED: patch "[PATCH] mm: introdu=
ce and use {pgd,p4d}_populate_kernel()" failed to apply to 5.15-stable tree
>   53 O   Sep 08 Harry Yoo       ( 273) =E2=94=9C=E2=94=80>[PATCH 5.15.y] =
mm: introduce and use {pgd,p4d}_populate_kernel()
>   54 O   Sep 09 Harry Yoo       ( 260) =E2=94=9C=E2=94=80>[PATCH V2 5.15.=
y] mm: introduce and use {pgd,p4d}_populate_kernel()
>   55 O   Sep 09 Harry Yoo       ( 262) =E2=94=94=E2=94=80>[PATCH V3 5.15.=
y] mm: introduce and use {pgd,p4d}_populate_kernel()
>=20
> The prompt includes extensive documentation about lore.kernel.org's search
> capabilities, limitations (like search index lag), and kernel workflow pa=
tterns
> to help AI agents effectively find related messages.
>=20
> Assisted-by: Claude Code

Hi Sasha,

it doesn't seem like Assisted-by is the right terminology here, as
the code itself makes me believe it was written wholesale by your
preferred LLM with minimal oversight, and then posted to the list.

A non-exhaustive code review inline, as it quickly became clear
this wasn't worth further time invested in reviewing.


> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
>  src/b4/command.py |  17 ++
>  src/b4/dig.py     | 630 ++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 647 insertions(+)
>  create mode 100644 src/b4/dig.py
>=20
> diff --git a/src/b4/command.py b/src/b4/command.py
> index 455124d..f225ae5 100644
> --- a/src/b4/command.py
> +++ b/src/b4/command.py
> @@ -120,6 +120,11 @@ def cmd_diff(cmdargs: argparse.Namespace) -> None:
>      b4.diff.main(cmdargs)
> =20
> =20
> +def cmd_dig(cmdargs: argparse.Namespace) -> None:
> +    import b4.dig
> +    b4.dig.main(cmdargs)
> +
> +
>  class ConfigOption(argparse.Action):
>      """Action class for storing key=3Dvalue arguments in a dict."""
>      def __call__(self, parser: argparse.ArgumentParser,
> @@ -399,6 +404,18 @@ def setup_parser() -> argparse.ArgumentParser:
>                            help=3D'Submit the token received via verifica=
tion email')
>      sp_send.set_defaults(func=3Dcmd_send)
> =20
> +    # b4 dig
> +    sp_dig =3D subparsers.add_parser('dig', help=3D'Use AI agent to find=
 related emails for a message')
> +    sp_dig.add_argument('msgid', nargs=3D'?',
> +                        help=3D'Message ID to analyze, or pipe a raw mes=
sage')
> +    sp_dig.add_argument('-o', '--output', dest=3D'output', default=3DNon=
e,
> +                        help=3D'Output mbox filename (default: <msgid>-r=
elated.mbox)')
> +    sp_dig.add_argument('-C', '--no-cache', dest=3D'nocache', action=3D'=
store_true', default=3DFalse,
> +                        help=3D'Do not use local cache when fetching mes=
sages')
> +    sp_dig.add_argument('--stdin-pipe-sep',
> +                        help=3D'When accepting messages on stdin, split =
using this pipe separator string')
> +    sp_dig.set_defaults(func=3Dcmd_dig)
> +
>      return parser
> =20
> =20
> diff --git a/src/b4/dig.py b/src/b4/dig.py
> new file mode 100644
> index 0000000..007f7d0
> --- /dev/null
> +++ b/src/b4/dig.py
> @@ -0,0 +1,630 @@
> +#!/usr/bin/env python3
> +# -*- coding: utf-8 -*-
> +# SPDX-License-Identifier: GPL-2.0-or-later
> +#
> +# b4 dig - Use AI agents to find related emails
> +#
> +__author__ =3D 'Sasha Levin <sashal@kernel.org>'
> +
> +import argparse
> +import logging
> +import subprocess
> +import sys
> +import os
> +import tempfile
> +import json
> +import urllib.parse
> +import gzip
> +import mailbox
> +import email.utils
> +from typing import Optional, List, Dict, Any
> +
> +import b4
> +
> +logger =3D b4.logger
> +
> +
> +def construct_agent_prompt(msgid: str) -> str:
> +    """Construct a detailed prompt for the AI agent to find related emai=
ls."""
> +
> +    # Clean up the message ID
> +    if msgid.startswith('<'):
> +        msgid =3D msgid[1:]
> +    if msgid.endswith('>'):
> +        msgid =3D msgid[:-1]

str.removeprefix and str.removesuffix exist for this precise purpose.

> [... snipped robot wrangling ...]
> +
> +
> +def call_agent(prompt: str, agent_cmd: str) -> Optional[str]:
> +    """Call the configured agent script with the prompt."""
> +
> +    # Expand user paths
> +    agent_cmd =3D os.path.expanduser(agent_cmd)
> +
> +    if not os.path.exists(agent_cmd):
> +        logger.error('Agent command not found: %s', agent_cmd)
> +        return None
> +
> +    if not os.access(agent_cmd, os.X_OK):
> +        logger.error('Agent command is not executable: %s', agent_cmd)
> +        return None

Why does this check exist? Why does the previous check exist? Wouldn't
it be better to just handle the exception subprocess.run will throw?

> +
> +    try:
> +        # Write prompt to a temporary file to avoid shell escaping issues
> +        with tempfile.NamedTemporaryFile(mode=3D'w', suffix=3D'.txt', de=
lete=3DFalse) as tmp:
> +            tmp.write(prompt)
> +            tmp_path =3D tmp.name

I'm so glad we now have tmp_path so I don't have to write out tmp.name ever=
y time

> +
> +        # Call the agent script with the prompt file as argument
> +        logger.info('Calling agent: %s %s', agent_cmd, tmp_path)
> +        result =3D subprocess.run(
> +            [agent_cmd, tmp_path],
> +            capture_output=3DTrue,
> +            text=3DTrue
> +        )
> +
> +        if result.returncode !=3D 0:
> +            logger.error('Agent returned error code %d', result.returnco=
de)
> +            if result.stderr:
> +                logger.error('Agent stderr: %s', result.stderr)
> +            return None
> +
> +        return result.stdout
> +
> +    except subprocess.TimeoutExpired:

You don't set a timeout in the subprocess.run parameters, so this
is dead code.

> +        logger.error('Agent command timed out after 5 minutes')
> +        return None
> +    except Exception as e:
> +        logger.error('Error calling agent: %s', e)
> +        return None
> +    finally:
> +        # Clean up temp file
> +        if 'tmp_path' in locals():
> +            try:
> +                os.unlink(tmp_path)
> +            except:
> +                pass

This is pointless. Had you (or rather, Claude doing business as you)
not set delete=3DFalse, and simply indented everything that needs the
temporary file to be within the `with` clause, then this code could
be removed.

> +
> +
> +def parse_agent_response(response: str) -> List[Dict[str, str]]:
> +    """Parse the agent's response to extract message IDs."""
> +
> +    related =3D []
> +
> +    try:
> +        # Try to find JSON in the response
> +        # Agent might return additional text, so we look for JSON array
> +        import re
> +        json_match =3D re.search(r'\[.*?\]', response, re.DOTALL)
> +        if json_match:
> +            json_str =3D json_match.group(0)
> +            data =3D json.loads(json_str)
> +
> +            if isinstance(data, list):
> +                for item in data:
> +                    if isinstance(item, dict) and 'msgid' in item:
> +                        related.append({
> +                            'msgid': item.get('msgid', ''),
> +                            'relationship': item.get('relationship', 're=
lated'),
> +                            'reason': item.get('reason', 'No reason prov=
ided')
> +                        })
> +        else:
> +            # Fallback: try to extract message IDs from plain text
> +            # Look for patterns that look like message IDs
> +            msgid_pattern =3D re.compile(r'[a-zA-Z0-9][a-zA-Z0-9\.\-_]+@=
[a-zA-Z0-9][a-zA-Z0-9\.\-]+\.[a-zA-Z]+')
> +            for match in msgid_pattern.finditer(response):
> +                msgid =3D match.group(0)
> +                if msgid !=3D '':  # Don't include the original
> +                    related.append({
> +                        'msgid': msgid,
> +                        'relationship': 'related',
> +                        'reason': 'Found in agent response'
> +                    })
> +
> +    except json.JSONDecodeError as e:
> +        logger.warning('Could not parse JSON from agent response: %s', e)
> +    except Exception as e:
> +        logger.error('Error parsing agent response: %s', e)
> +
> +    return related
> +
> +
> +def get_message_info(msgid: str) -> Optional[Dict[str, Any]]:
> +    """Retrieve basic information about a message."""
> +
> +    msgs =3D b4.get_pi_thread_by_msgid(msgid, onlymsgids=3D{msgid}, with=
_thread=3DFalse)
> +    if not msgs:
> +        return None
> +
> +    msg =3D msgs[0]
> +
> +    return {
> +        'subject': msg.get('Subject', 'No subject'),
> +        'from': msg.get('From', 'Unknown'),
> +        'date': msg.get('Date', 'Unknown'),
> +        'msgid': msgid
> +    }
> +
> +
> +def download_and_combine_threads(msgid: str, related_messages: List[Dict=
[str, str]],
> +                                 output_file: str, nocache: bool =3D Fal=
se) -> int:
> +    """Download thread mboxes for all related messages and combine into =
one mbox file."""
> +
> +    message_ids =3D [msgid]  # Start with original message
> +
> +    # Add all related message IDs
> +    for item in related_messages:
> +        if 'msgid' in item:
> +            message_ids.append(item['msgid'])
> +
> +    # Collect all messages from all threads
> +    seen_msgids =3D set()
> +    all_messages =3D []
> +
> +    # Download thread for each message
> +    # But be smart about what we include - don't mix unrelated series
> +    for msg_id in message_ids:
> +        logger.info('Fetching thread for %s', msg_id)
> +
> +        # For better control, fetch just the specific thread, not everyt=
hing
> +        # Use onlymsgids to limit scope when possible
> +        msgs =3D b4.get_pi_thread_by_msgid(msg_id, nocache=3Dnocache)
> +
> +        if msgs:
> +            # Try to detect thread boundaries and avoid mixing unrelated=
 series
> +            thread_messages =3D []
> +            base_subject =3D None
> +
> +            for msg in msgs:
> +                msg_msgid =3D b4.LoreMessage.get_clean_msgid(msg)
> +
> +                # Skip if we've already seen this message
> +                if msg_msgid in seen_msgids:
> +                    continue
> +
> +                # Get the subject to check if it's part of the same seri=
es
> +                subject =3D msg.get('Subject', '')
> +
> +                # Extract base subject (remove Re:, [PATCH], version num=
bers, etc)
> +                import re
> +                base =3D re.sub(r'^(Re:\s*)*(\[.*?\]\s*)*', '', subject)=
=2Estrip()
> +
> +                # Set the base subject from the first message
> +                if base_subject is None and base:
> +                    base_subject =3D base
> +
> +                # Add the message
> +                if msg_msgid:
> +                    seen_msgids.add(msg_msgid)
> +                    thread_messages.append(msg)
> +
> +            all_messages.extend(thread_messages)
> +        else:
> +            logger.warning('Could not fetch thread for %s', msg_id)
> +
> +    # Sort messages by date to maintain chronological order
> +    all_messages.sort(key=3Dlambda m: email.utils.parsedate_to_datetime(=
m.get('Date', 'Thu, 1 Jan 1970 00:00:00 +0000')))
> +
> +    # Write all messages to output mbox file using b4's proper mbox func=
tions
> +    logger.info('Writing %d messages to %s', len(all_messages), output_f=
ile)
> +
> +    total_messages =3D len(all_messages)
> +
> +    if total_messages > 0:
> +        # Use b4's save_mboxrd_mbox function which properly handles mbox=
 format
> +        with open(output_file, 'wb') as outf:
> +            b4.save_mboxrd_mbox(all_messages, outf)
> +
> +    logger.info('Combined mbox contains %d unique messages', total_messa=
ges)
> +    return total_messages
> +
> +
> +def main(cmdargs: argparse.Namespace) -> None:
> +    """Main entry point for b4 dig command."""
> +
> +    # Get the message ID
> +    msgid =3D b4.get_msgid(cmdargs)
> +    if not msgid:
> +        logger.critical('Please provide a message-id')
> +        sys.exit(1)
> +
> +    # Clean up message ID
> +    if msgid.startswith('<'):
> +        msgid =3D msgid[1:]
> +    if msgid.endswith('>'):
> +        msgid =3D msgid[:-1]

Well, good thing we're duplicating the subpar code from before.

> +
> +    logger.info('Analyzing message: %s', msgid)
> +
> +    # Get the agent command from config
> +    config =3D b4.get_main_config()
> +    agent_cmd =3D None
> +
> +    # Check command-line config override
> +    if hasattr(cmdargs, 'config') and cmdargs.config:
> +        if 'AGENT' in cmdargs.config:
> +            agent_cmd =3D cmdargs.config['AGENT']

dict.get exists

> +
> +    # Fall back to main config
> +    if not agent_cmd:
> +        agent_cmd =3D config.get('dig-agent', config.get('agent', None))
> +
> +    if not agent_cmd:
> +        logger.critical('No AI agent configured. Set dig-agent in config=
 or use -c AGENT=3D/path/to/agent.sh')
> +        logger.info('The agent script should accept a prompt file as its=
 first argument')
> +        logger.info('and return a JSON array of related message IDs to s=
tdout')
> +        sys.exit(1)
> +
> +    # Get info about the original message
> +    logger.info('Fetching original message...')
> +    msg_info =3D get_message_info(msgid)
> +    if msg_info:
> +        logger.info('Subject: %s', msg_info['subject'])
> +        logger.info('From: %s', msg_info['from'])
> +    else:
> +        logger.warning('Could not retrieve original message info')
> +
> +    # Construct the prompt
> +    logger.info('Constructing agent prompt...')
> +    prompt =3D construct_agent_prompt(msgid)
> +
> +    # Call the agent
> +    logger.info('Calling AI agent: %s', agent_cmd)
> +    response =3D call_agent(prompt, agent_cmd)
> +
> +    if not response:
> +        logger.critical('No response from agent')
> +        sys.exit(1)
> +
> +    # Parse the response
> +    logger.info('Parsing agent response...')
> +    related =3D parse_agent_response(response)
> +
> +    if not related:
> +        logger.info('No related messages found')
> +        sys.exit(0)
> +
> +    # Display simplified results
> +    logger.info('Found %d related messages:', len(related))
> +    print()
> +    print('Related Messages Summary:')
> +    print('-' * 60)
> +
> +    for item in related:
> +        relationship =3D item.get('relationship', 'related')
> +        reason =3D item.get('reason', '')
> +
> +        print(f'[{relationship.upper()}] {reason}')
> +
> +    print('-' * 60)
> +    print()
> +
> +    # Generate output mbox filename
> +    if hasattr(cmdargs, 'output') and cmdargs.output:
> +        mbox_file =3D cmdargs.output
> +    else:
> +        # Use message ID as base for filename, sanitize it
> +        safe_msgid =3D msgid.replace('/', '_').replace('@', '_at_').repl=
ace('<', '').replace('>', '')

str.translate exists

> +        mbox_file =3D f'{safe_msgid}-related.mbox'
> +
> +    # Download and combine all threads into one mbox
> +    logger.info('Downloading and combining all related threads...')
> +    nocache =3D hasattr(cmdargs, 'nocache') and cmdargs.nocache

dict.get exists

> +    total_messages =3D download_and_combine_threads(msgid, related, mbox=
_file, nocache=3Dnocache)
> +
> +    if total_messages > 0:
> +        logger.info('Success: Combined mbox saved to %s (%d messages)', =
mbox_file, total_messages)
> +        print(f'=E2=9C=93 Combined mbox file: {mbox_file}')
> +        print(f'  Total messages: {total_messages}')
> +        print(f'  Related threads: {len(related) + 1}')  # +1 for origin=
al
> +    else:
> +        logger.warning('No messages could be downloaded (they may not ex=
ist in the archive)')
> +        print('=E2=9A=A0 No messages were downloaded - they may not exis=
t in the archive yet')
> +        # Still exit with success since we found relationships
> +        sys.exit(0)
>=20

I did not even remotely look over all the code, but when people on
your other agentic evangelism series pointed out how it'll result in
lazy patches from people who should know better, then this is kind of
the type of thing they probably meant.




From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 DD9D75BAF0;
	Thu, 11 Sep 2025 15:05:24 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757603125; cv=none; b=Ql4spmNHWY2A1/InQ+bKTPpBWV6J8+f1YePWl8xpa/RWuENZ6Le63ibChJvA8pkwtsKFRwjYJYdOs40tA/jmQOzZCY4FMLdT5IbYZl0qfVm7Oa+CFlcNH6LhZNnWguOZQIXyIO/cww5JQ5PrUtEK3e9ZBoLG9i1s9FgrsrP6Lac=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757603125; c=relaxed/simple;
	bh=kTQb11opTChZNj9h0F9lpqMyV8HyWYBUbODPI2uv1g4=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=CKm07QWSm2A5IzIaXG9qAfZIhAzB1ZXejoMa7h33qxXQfb0ivu4zCiNUAfU5yTfSlL250VRmy5scy4omkxqubh8ndTcEvqPIPfHfhG/XVUMnTEbiPg3J8RZAdsOAMtkUfVgA+/UABPUCx4TVy5KdItSohB5lBs2I3hbCooY+eyM=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cfRn8LBN; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cfRn8LBN"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8FFB0C4CEF0;
	Thu, 11 Sep 2025 15:05:24 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757603124;
	bh=kTQb11opTChZNj9h0F9lpqMyV8HyWYBUbODPI2uv1g4=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=cfRn8LBN53W3g5rxlQyxFm9pg6iuwk5hR9MpMntJzFI8B85qH5c2dgTdUeB5DSDXo
	 mfijwuL5gAa49jlXr1/+Pt5sE41LWVAUQdrqg5Q+/KfLyWMidzMDhOuMg+fkqHPSMm
	 VBwqg3wfmCYigH3EXkbrXeJTgPynnm2hP7q8oHjE6yzTKZ6+pXIgiJwBE39czK8o0O
	 j1ln/pL+G6ba8LaJqPK7ecTpr3pn01jk7SbOTe/OuiaziryMDMkcBDj8k/UtoahZEm
	 lbyfEcP0KE3zKYRwXhP2MIEe/LT20FAMirThk/jU3c1Ds0wj9hd/E9JXd6cvO5vSYi
	 WypGneMjpBDsA==
Date: Thu, 11 Sep 2025 11:05:23 -0400
From: Sasha Levin <sashal@kernel.org>
To: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Cc: konstantin@linuxfoundation.org, axboe@kernel.dk,
	csander@purestorage.com, io-uring@vger.kernel.org,
	torvalds@linux-foundation.org, workflows@vger.kernel.org
Subject: Re: [RFC] b4 dig: Add AI-powered email relationship discovery command
Message-ID: <aMLlMz_ujgditm4c@laps>
References: <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <20250909163214.3241191-1-sashal@kernel.org>
 <4764751.e9J7NaK4W3@workhorse>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <4764751.e9J7NaK4W3@workhorse>

On Thu, Sep 11, 2025 at 04:48:03PM +0200, Nicolas Frattaroli wrote:
>On Tuesday, 9 September 2025 18:32:14 Central European Summer Time Sasha Levin wrote:
>it doesn't seem like Assisted-by is the right terminology here, as
>the code itself makes me believe it was written wholesale by your
>preferred LLM with minimal oversight, and then posted to the list.
>
>A non-exhaustive code review inline, as it quickly became clear
>this wasn't worth further time invested in reviewing.

Thanks for the review!

Indeed, Python isn't my language of choice: this script was a difficult (for
me) attempt at translating an equivalent bash based script that I already had
into python so it could fit into b4.

My intent was for this to start a discussion about this approach rather than
actually be merged into b4.

-- 
Thanks,
Sasha

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from sender4-pp-f112.zoho.com (sender4-pp-f112.zoho.com [136.143.188.112])
	(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 1DC3F17C21C;
	Thu, 11 Sep 2025 19:13:44 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=136.143.188.112
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757618027; cv=pass; b=K5/vp0251Z1snRAlB2AlWH/m7z4d+syePiPQjWPm4a1XZYkdn/ov8EAZyngaj0gyueAm4aW+5ekABaPULJqwoAIME4Fmn6KCrVR5jI+RJuRYaP2or35ucWxqpPaKCPWg9f+pVcE4qOOfy5/jkvhAremzSF6dJpuAinw0eENpCtU=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757618027; c=relaxed/simple;
	bh=/y2tq5te3Hj2LI91DCTQpf3xen1/iW0P6TT+yTgBKQY=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version:Content-Type; b=s20UL9HgT9WnKlTkTT+cdGDuJA0zXi63ASK4DR58x2tlr/9dW9jbs1A86PA/DCffmnbacQP4GgbNKHCmdIvWY75/caVn9PNTLOctFoYY5kt08jDhja+s3y5jqNaoM+BW6QZowBV53dCEUsRCFi9JI4/evYNlGKVw1uCgP19egZ8=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (1024-bit key) header.d=collabora.com header.i=nicolas.frattaroli@collabora.com header.b=UOEcDbdD; arc=pass smtp.client-ip=136.143.188.112
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=collabora.com header.i=nicolas.frattaroli@collabora.com header.b="UOEcDbdD"
ARC-Seal: i=1; a=rsa-sha256; t=1757618014; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=nkXkMBYuB0fMP4rM+ri0ba9ivOgkd18FJpOPQodcBczYjPhD8D2uAidm82JOGudYoywD8s7GCjucbpvU9VBUAn63XUv7GggyDCXqGqBXzr1xrw2yq7MZvwJYfVm9pjQKR8UG+d4Y677hSlhvAmRby1r4q9ShaZyhntYyjezSOMU=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1757618014; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=L2UVdjsYZJkAnBBvIllckgQMsXgXuSQjpas1+bmt/EI=; 
	b=FxPsKOI78ZnzdPWaZ+al4EzmRrkvykuDshZui7tLWBF7sbvT8ODA1IoSKntKs9veZ2ZiYXOds9CA4QThjaHNUeXEPGWNmSwIH6kp9AD4t4Y/10SY82gf4/x2nsjyU67Wm48YA2LkB9SLRAUxZc9APsbG4/D7Ik7tnfa9+y7ivUU=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=collabora.com;
	spf=pass  smtp.mailfrom=nicolas.frattaroli@collabora.com;
	dmarc=pass header.from=<nicolas.frattaroli@collabora.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1757618014;
	s=zohomail; d=collabora.com; i=nicolas.frattaroli@collabora.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-ID:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Reply-To;
	bh=L2UVdjsYZJkAnBBvIllckgQMsXgXuSQjpas1+bmt/EI=;
	b=UOEcDbdDZXKH4kaBz8Gn0vu7mjxH9Ii+j4JLTrFG2YP00DrszIZ0D1kMpqHgONPT
	nN5EeJin6eIhxSKGkAVO090A2EMabXjJLdskdoWlRM8QU3SFwq3xJ2P7nwtC1Eha0vO
	OIIudVLSjGqkG3Eiet+rqTZmIH1WaM26Ek2E60Gw=
Received: by mx.zohomail.com with SMTPS id 1757618012484692.4540050345284;
	Thu, 11 Sep 2025 12:13:32 -0700 (PDT)
From: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
To: Sasha Levin <sashal@kernel.org>
Cc: konstantin@linuxfoundation.org, axboe@kernel.dk, csander@purestorage.com,
 io-uring@vger.kernel.org, torvalds@linux-foundation.org,
 workflows@vger.kernel.org,
 Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [RFC] b4 dig: Add AI-powered email relationship discovery command
Date: Thu, 11 Sep 2025 21:13:28 +0200
Message-ID: <4278380.jE0xQCEvom@workhorse>
In-Reply-To: <aMLlMz_ujgditm4c@laps>
References:
 <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <4764751.e9J7NaK4W3@workhorse> <aMLlMz_ujgditm4c@laps>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="utf-8"

On Thursday, 11 September 2025 17:05:23 Central European Summer Time Sasha Levin wrote:
> On Thu, Sep 11, 2025 at 04:48:03PM +0200, Nicolas Frattaroli wrote:
> >On Tuesday, 9 September 2025 18:32:14 Central European Summer Time Sasha Levin wrote:
> >it doesn't seem like Assisted-by is the right terminology here, as
> >the code itself makes me believe it was written wholesale by your
> >preferred LLM with minimal oversight, and then posted to the list.
> >
> >A non-exhaustive code review inline, as it quickly became clear
> >this wasn't worth further time invested in reviewing.
> 
> Thanks for the review!
> 
> Indeed, Python isn't my language of choice: this script was a difficult (for
> me) attempt at translating an equivalent bash based script that I already had
> into python so it could fit into b4.

There's something to be said about these tools' habit of empowering
people to think they can judge the output adequately, but I don't
want to detract from the other point I'll try to make in this reply.

> My intent was for this to start a discussion about this approach rather than
> actually be merged into b4.

I know that, and you did get feedback on this approach already from
others, specifically that it did not solve the core issue that is
poorly utilised metadata and instead applies hammer to vaguely nail
shaped thing.

And your reaction was to call them personally biased against this
approach, and to loudly announce you would ignore any further
e-mails from them.

Now while I won't claim Laurent Pinchart isn't one of the louder
critics of your recent LLM evangelism, I can't really see a fault
in his reasoning: your insistence on finding an LLM solution to
every and any problem is papering over the real pain point,
which is that Link: should contain useful information, so that
you can click on the link and get the information and not have
to do a search (LLM assisted or not) for said information.

So the responses you expect to this patch should seemingly meet the
following two criteria:
1. we're not supposed to critique the implementation, as it's an RFC
   and therefore should not get comments on anything but the general
   approach,
2. we're not supposed to critique the general approach, because saying
   that this solution is neither reliable nor efficient is a result
   of personal bias against the underlying technology.

I don't condone the arguments based on energy usage because any use
of electricity in a grid that's not decarbonised will be open to
value judgements. For example, my personal non-workplace-endorsed
opinion is that electricity used on growing zucchini is wasted,
as they are low-nutrient snot pumpkins masquerading as cucumbers.

My main criticism on the approach end of things, if I am allowed
an opinion, is that this does not make Link: tags more meaningful,
nor does it solve the problem of automated tools adding sometimes
useless noise to something humans are supposed to be reading (which,
some may point out, your tool makes even worse.)

While bisecting, I often come across things where I'd love to be
able to immediately see what discussion preceded the problematic
patch with just one click and pageload between. Shoveling GPUs
into Sam Altman's gaping cheeks does not allow me to do that,
or at least not any better than a search on lore with dfn: would
already allow me to do.




From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 7CF4C4315F;
	Thu, 11 Sep 2025 19:57:32 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757620652; cv=none; b=mLPGKTXWURtz5cID0Svg8snb59JTp7kzdhop8lDH5nY8ivuHZnLim6XKg2bOFICMNhphW9wC6tdq17ec7DudxPKdVanGRzy46eDTzijGQWfFzxfm/zwnSz2LK8E63lYPLsFSebAk3/POWO9XyVtXBaKAZ3ss/KejgQSiN2uiiN0=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757620652; c=relaxed/simple;
	bh=CDgN5H623d0hg9fcWZA4yJC8NpwZk7KWxKm3tD91rVk=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=Q4umuv143W49q1MbXHdNMbtAGmj5UlhekpwyQUzDcTxekkZcUONWATz4HfCqMomsY6kCeb20XafYFQnIpkAwBHNnynXvqA2++1+auYPYiXS8EcNDFWvZuwsH9iu7rpHODaKKhk1YTHq//QVZliXEMdQtBSX3lXfdcdMAw1FvsKc=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MQmnlV9Y; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MQmnlV9Y"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id DE459C4CEF0;
	Thu, 11 Sep 2025 19:57:31 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757620652;
	bh=CDgN5H623d0hg9fcWZA4yJC8NpwZk7KWxKm3tD91rVk=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=MQmnlV9YMOW4cDAEQcyqqSD4W2zNmNRLMuruRxTK1fvOpRaubs1CK9Is6rWFZqfKX
	 xscnKwBgWT7/rhA7ns9zY9fl+2XcrR4a2VZRHhUlNJ8x6Jtyp09gyuwDKb0cWPQJNE
	 Nh8udD7WrZX5CJZ6nVA00XKIf6b1sg00MFvdnbyMbxJUBnpBxk/dZpwRQkPX8vj/AN
	 1+BwXJmKNXNiSFW5XSWJqHYPiYTDJXJXXkbrZHKuHmQn3lviJflofF8nIZDUIYVQ+L
	 aY2z1Sa5dUd5vOdtVSMRaSRjU42IjUl45tA2cUtIa9cUu0d/iRGrsQicEd78xlZ830
	 EKTk+7gIXDjCA==
Date: Thu, 11 Sep 2025 15:57:30 -0400
From: Sasha Levin <sashal@kernel.org>
To: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Cc: konstantin@linuxfoundation.org, axboe@kernel.dk,
	csander@purestorage.com, io-uring@vger.kernel.org,
	torvalds@linux-foundation.org, workflows@vger.kernel.org,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [RFC] b4 dig: Add AI-powered email relationship discovery command
Message-ID: <aMMpqojURAZa7cPU@laps>
References: <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <4764751.e9J7NaK4W3@workhorse>
 <aMLlMz_ujgditm4c@laps>
 <4278380.jE0xQCEvom@workhorse>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <4278380.jE0xQCEvom@workhorse>

On Thu, Sep 11, 2025 at 09:13:28PM +0200, Nicolas Frattaroli wrote:
>On Thursday, 11 September 2025 17:05:23 Central European Summer Time Sasha Levin wrote:
>> On Thu, Sep 11, 2025 at 04:48:03PM +0200, Nicolas Frattaroli wrote:
>> >On Tuesday, 9 September 2025 18:32:14 Central European Summer Time Sasha Levin wrote:
>> >it doesn't seem like Assisted-by is the right terminology here, as
>> >the code itself makes me believe it was written wholesale by your
>> >preferred LLM with minimal oversight, and then posted to the list.
>> >
>> >A non-exhaustive code review inline, as it quickly became clear
>> >this wasn't worth further time invested in reviewing.
>>
>> Thanks for the review!
>>
>> Indeed, Python isn't my language of choice: this script was a difficult (for
>> me) attempt at translating an equivalent bash based script that I already had
>> into python so it could fit into b4.
>
>There's something to be said about these tools' habit of empowering
>people to think they can judge the output adequately, but I don't
>want to detract from the other point I'll try to make in this reply.
>
>> My intent was for this to start a discussion about this approach rather than
>> actually be merged into b4.
>
>I know that, and you did get feedback on this approach already from
>others, specifically that it did not solve the core issue that is
>poorly utilised metadata and instead applies hammer to vaguely nail
>shaped thing.
>
>And your reaction was to call them personally biased against this
>approach, and to loudly announce you would ignore any further
>e-mails from them.
>
>Now while I won't claim Laurent Pinchart isn't one of the louder
>critics of your recent LLM evangelism, I can't really see a fault
>in his reasoning: your insistence on finding an LLM solution to
>every and any problem is papering over the real pain point,
>which is that Link: should contain useful information, so that
>you can click on the link and get the information and not have
>to do a search (LLM assisted or not) for said information.
>
>So the responses you expect to this patch should seemingly meet the
>following two criteria:
>1. we're not supposed to critique the implementation, as it's an RFC
>   and therefore should not get comments on anything but the general
>   approach,
>2. we're not supposed to critique the general approach, because saying
>   that this solution is neither reliable nor efficient is a result
>   of personal bias against the underlying technology.
>
>I don't condone the arguments based on energy usage because any use
>of electricity in a grid that's not decarbonised will be open to
>value judgements. For example, my personal non-workplace-endorsed
>opinion is that electricity used on growing zucchini is wasted,
>as they are low-nutrient snot pumpkins masquerading as cucumbers.
>
>My main criticism on the approach end of things, if I am allowed
>an opinion, is that this does not make Link: tags more meaningful,
>nor does it solve the problem of automated tools adding sometimes
>useless noise to something humans are supposed to be reading (which,
>some may point out, your tool makes even worse.)
>
>While bisecting, I often come across things where I'd love to be
>able to immediately see what discussion preceded the problematic
>patch with just one click and pageload between. Shoveling GPUs
>into Sam Altman's gaping cheeks does not allow me to do that,
>or at least not any better than a search on lore with dfn: would
>already allow me to do.

I very much agree with your general observation:

1. I don't think that this script solves the underlying Link: issue.

2. It papers over the real problem

3. I don't think that today's LLMs can solve any fundamental issue we're facing
in kernel-land.

4. I am really happy (as Laurent said) to apply my big hammer to anything that
looks like a nail.


We've started[1] the workflows@ list (which is how I stumbled on this thread)
about 5-6 years ago when the concern from multiple maintainers was that we all
have our magical scripts, they are seriously ugly, and everyone are ashamed of
sharing them. So this list was an effort to get the ball rolling on folks
sharing some of those ugly workflows and scripts in an attempt to standardize
and improve our processes.

I've shared this very hacky b4-dig script as exactly that: I have a very ugly
bash script that addresses some of the issues Linus brought up around being
able to find more context for a given patch/mail.  I use that script often, it
helps me spend less time on browsing lore (no, dfn: won't find you syzbot
reports or CI failures), and it just "works for me".

I'd love if we end up with a great solution for Link:, I'm not asking anyone to
stop working on that, nor am I claiming that this is a good long-term solution
for the problem. All this is is a utility script that fits my needs *TODAY*.

So no, I wasn't looking for criticism on workflows@ (this isn't even on lkml,
ksummit-discuss, or anything like that).  I was looking to share a workflow
that I have and see if folks have any ideas, suggestions, or would potentially
want to do something like this on their own.  I wasn't looking for an almost
religious "vim vs. emacs"-esque choire of "LLMS SUCK" or comments about Sam
Altman's rear end.

Maybe this is why folks are reluctant to share their ugly scripts?



[1] https://lwn.net/Articles/799134/ - "The session closed with the creation of
a new "workflows" mailing list on vger.kernel.org where developers can discuss
how they work and share their scripts".

-- 
Thanks,
Sasha

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 295AF2E1F1C;
	Thu, 11 Sep 2025 23:24:04 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757633045; cv=none; b=DtFMwt5K+CpIDIz5DImJyD4WNbWnchoogN/QbMRu9JJrU8KcneYGn4UWgjsVrC/25IF4WY+aQNGAiIPUYCzB6CFy8Vt4u3Cfcsd8O3YqpOLP7MRfqdrBNBpEz21ArEMypvtj5p4t3DbMlnbLaDheDrItqR6JQ7kuNAOLJ5pQfLo=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757633045; c=relaxed/simple;
	bh=4RN4G5nFo80zxCLbZcaoPW0025YHvftVo4h5LujOgBQ=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=pgwNIXDb9fFXQs6UCqpV50qCSpFkBpzK+MS6uho+fVyrs8Uj2C4vsHEwICr7OFwbrr8DxRzBoSWW6RZ0Sh/Ys2M1EStTCYl5MDc88zgOahbdSkNZuSPtG9MDfeRcBMxqWyEP2DspV7Y0KXZb7vyNSlKzXgNxvwaMNig5ZIfpHm4=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=BhFmptbu; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="BhFmptbu"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7DB4BC4CEF0;
	Thu, 11 Sep 2025 23:24:04 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1757633044;
	bh=4RN4G5nFo80zxCLbZcaoPW0025YHvftVo4h5LujOgBQ=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=BhFmptbudL5b4JuehsACTMNCDxRh1Iw5069gjzBBhmvSipn230PVP9TvP/Y8+/bC8
	 yHXoPSyhdgzzNuxRqxI9lqumES5RHlIz73BMw1Q+NzMXXk94QXrB4oYFLZZ/teOu+f
	 4eRWwL4bwfLyaljawjJpq7Na9EEmwcAYOIFl4CKc=
Date: Thu, 11 Sep 2025 19:24:03 -0400
From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: Sasha Levin <sashal@kernel.org>
Cc: axboe@kernel.dk, csander@purestorage.com, io-uring@vger.kernel.org, 
	torvalds@linux-foundation.org, workflows@vger.kernel.org
Subject: Re: [RFC] b4 dig: Add AI-powered email relationship discovery command
Message-ID: <20250911-neon-speedy-walrus-dcc499@meerkat>
References: <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <20250909163214.3241191-1-sashal@kernel.org>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250909163214.3241191-1-sashal@kernel.org>

On Tue, Sep 09, 2025 at 12:32:14PM -0400, Sasha Levin wrote:
> Add a new 'b4 dig' subcommand that uses AI agents to discover related
> emails for a given message ID. This helps developers find all relevant
> context around patches including previous versions, bug reports, reviews,
> and related discussions.

All right, I've got ollama working on my gaming rig now, so that I can get
back to my summarization work without having to rely on big vendors. Thanks
for pushing me in that direction, because it never felt quite right to be
using a centralized service for this work. At least that large nvidia card
does something other than help me deliver packages to Port Knot City.

> The command:
> - Takes a message ID and constructs a detailed prompt about email relationships
> - Calls a configured AI agent script to analyze and find related messages
> - Downloads all related threads from lore.kernel.org
> - Combines them into a single mbox file for easy review

I'm going to take a look at it, but I want to use "b4 dig" to analyze commits
and establish their provenance. I will then look at whether we can use LLMs to
provide additional perks like summarization or highlights of important
messages (those offering nacks, criticisms, warnings, etc). This seems like the
"least wrong" way of using an LLM at this moment, especially with the legality
of the code it produces still largely untested in courts.

Thanks for submitting this to push me into this direction. I won't take this
directly, but I'll rely on it to see how you get certain things done.

Regards,
-K

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 B8C1A2DA776;
	Mon, 15 Sep 2025 11:26:46 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757935606; cv=none; b=CD7aVyCAleR73xGey07ze7Z1c7Izce/+5DJDmtwqZHNC7l2T/2MHjaFMu+m6sdxQMHAiW3K4hquTKG70nVnI6K8wK8XWNS1mtVowXWioNlL30ATYtKmU7HXlvh93quyQjqXMaoSFtjjkFBN/wa6dDPfKiEzuAhLhgvsyB6NerUM=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757935606; c=relaxed/simple;
	bh=MTehY0L7uXZCtPEzcuwk4qrp/9Xzk7WlwWtRRzf69nM=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=XYaVmfaaq2LHhHTjlvmyyGdU37q4YRd55kmwJojeOs9JjYCkzgF9UZH8zr3JnwjnEbaKNi1Y27v3E/sD+2SgIiK0lQbPAtcuNFFjwfuxSQhTGKRMz2bq3Zvzsv5o10NV40ld0gWJc8+E8jZY7a0Sswwm7TMpyr+uQPycKjkBArc=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ja2DteoC; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ja2DteoC"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 799B6C4CEF5;
	Mon, 15 Sep 2025 11:26:44 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757935606;
	bh=MTehY0L7uXZCtPEzcuwk4qrp/9Xzk7WlwWtRRzf69nM=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=Ja2DteoCLWBcoQe/EXbxKqauAGJ4iwyxNYv7AoxghgC5mJ3xo4QWm9XvLYKDjZ6pL
	 vfY0ONPbDs4dBFqb0QVkKsXSCBPamLAC2bsu2eqXKZ8EBqT8FBwOCZaO5dGjtG0tj1
	 YWviD32b6yhr9MeWyDhlIAJxGgxoEgXOk1MwhrIM/1mupxfww5bN6SoQMkM0F4dfYf
	 3cu++4MzXsD5TUxXRYrcF9Nh7RBC2/H5/jkdeu53vm1iCx6jZrSnIgS9ZLfXbYaxyM
	 /JZKnl/j/UUxTHxsewbiFWDiv9pOGs5rlabExKW30rF/th9HC7ks5po4RBkXIpzXCm
	 1Sq4ZkKh+l/Pg==
Date: Mon, 15 Sep 2025 12:26:41 +0100
From: Mark Brown <broonie@kernel.org>
To: Sasha Levin <sashal@kernel.org>
Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>,
	konstantin@linuxfoundation.org, axboe@kernel.dk,
	csander@purestorage.com, io-uring@vger.kernel.org,
	torvalds@linux-foundation.org, workflows@vger.kernel.org,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [RFC] b4 dig: Add AI-powered email relationship discovery command
Message-ID: <6e25b2e7-67a2-4a92-95d5-adb279e811a7@sirena.org.uk>
References: <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <4764751.e9J7NaK4W3@workhorse>
 <aMLlMz_ujgditm4c@laps>
 <4278380.jE0xQCEvom@workhorse>
 <aMMpqojURAZa7cPU@laps>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="NgoFlW9mbzgjnno5"
Content-Disposition: inline
In-Reply-To: <aMMpqojURAZa7cPU@laps>
X-Cookie: We've upped our standards, so up yours!


--NgoFlW9mbzgjnno5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 11, 2025 at 03:57:30PM -0400, Sasha Levin wrote:

> We've started[1] the workflows@ list (which is how I stumbled on this thr=
ead)
> about 5-6 years ago when the concern from multiple maintainers was that w=
e all
> have our magical scripts, they are seriously ugly, and everyone are asham=
ed of
> sharing them. So this list was an effort to get the ball rolling on folks
> sharing some of those ugly workflows and scripts in an attempt to standar=
dize
> and improve our processes.

> I've shared this very hacky b4-dig script as exactly that: I have a very =
ugly
> bash script that addresses some of the issues Linus brought up around bei=
ng
> able to find more context for a given patch/mail.  I use that script ofte=
n, it
> helps me spend less time on browsing lore (no, dfn: won't find you syzbot
> reports or CI failures), and it just "works for me".

This seems like a great example of a situation where the suggestions
=66rom one of the other thread of asking people to clearly mark when patch
submissions are using these tools would have helped - had the submission
described the above then the Python level review would've gone a lot
differently I think.  Realising during review is a totally different
experience to being told up front.

--NgoFlW9mbzgjnno5
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmjH9/AACgkQJNaLcl1U
h9A7Wwf/beY2mgQEzSNuH//PeCC2wwtz5SKeaxX3/H7dBle9cqLQag46TsbxYgkZ
ahjRVZP44x/QoF10zwmVQ31vBVKlcGi78TBmmjpUrAMkPn5GZTMdBrTotUwnqyJE
uqaPDhU3LC9Q5M0HKJtfV0ntBrZIVVDGYQxcU89GED5m/ZFmZF6NDejJWDW87K96
8P9e+2Eqt4fB3qQqkRJSdeFfTMGnIW0KZEjyMN/KAydh6X1paG6rPXNUTtgRAybl
1crvZGjC3Ag959QcKjB/VbEeIJjk5SWq+jXfg7+ofMTN/7AAWa3Vz7E7AODz7ptn
Z7o5X8IjxnNtnKyMrlemCresCauiWQ==
=Zh1E
-----END PGP SIGNATURE-----

--NgoFlW9mbzgjnno5--

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 78C5B1397;
	Mon, 15 Sep 2025 11:48:39 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757936919; cv=none; b=qIXZav9yCJCf4VUmUTWoOdBw0Z0ZRc3Plzl4LIR+q6z3nZd6BBlHd+Hgd7ZdbooPp5fuuhNZWsUiM++/c3JDxBmYHiN7Et9t/OXZsEr5ZNjmZf9kShFgIG+sF2xhjUmTj7ecVIShHD+1fTocWQ0iO7OWf3nJOQDfj7/toVUPrAk=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757936919; c=relaxed/simple;
	bh=EFzV0A6vIaZngi/ZXutYPmUuHt4mEkkefaQljnOFnTw=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=RBA0y/hItVHpV88mAO2Rd+e0KKupo2J9FKrjLJkGvJdbMPzIo48dhyEknRcA0iuZdAIysqjqK+ZYLiMWpDrMEPOKS1YZp7xVgnV5bCQ+jqj59K+2XfY21v7zrudNEeMXRfRy3Q4mypFj6tWXHRwS30kMFbXvMgVFzVKpWF5j7ys=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rT/cuUAy; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rT/cuUAy"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0006BC4CEF1;
	Mon, 15 Sep 2025 11:48:38 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757936919;
	bh=EFzV0A6vIaZngi/ZXutYPmUuHt4mEkkefaQljnOFnTw=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=rT/cuUAyl7sBs731pqIDPOYaTcziWqUpP1Z34dNuYpSDHEPgweUE8GwXxKPlkKDGz
	 2TVWgxeeqeM8eSxUQhj4aHip459M4enseiwhLgORVeMymtW5RcmglZmxn+WGdUSkQs
	 erXy1Yb5a+uzTKSxle4IPecFz7RO/nT7el5yd70TVbejdZzSEQM6MlUJ2nwahqjCYd
	 uPuo/kGysds0lAx97qA4/cQqbDBL6CWH7quiJKuiXAb+RTtRvUdDxH/imi7/cAok74
	 TugL755/fIJcto9c9kH6MVuPM4e+IuYre7dGJr01z5Pqrl1c6tEvgsdIfH5YtXAWKY
	 6TnAsVuJuEOWg==
Date: Mon, 15 Sep 2025 07:48:37 -0400
From: Sasha Levin <sashal@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>,
	konstantin@linuxfoundation.org, axboe@kernel.dk,
	csander@purestorage.com, io-uring@vger.kernel.org,
	torvalds@linux-foundation.org, workflows@vger.kernel.org,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [RFC] b4 dig: Add AI-powered email relationship discovery command
Message-ID: <aMf9FaDxGY4nYI2f@laps>
References: <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <4764751.e9J7NaK4W3@workhorse>
 <aMLlMz_ujgditm4c@laps>
 <4278380.jE0xQCEvom@workhorse>
 <aMMpqojURAZa7cPU@laps>
 <6e25b2e7-67a2-4a92-95d5-adb279e811a7@sirena.org.uk>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <6e25b2e7-67a2-4a92-95d5-adb279e811a7@sirena.org.uk>

On Mon, Sep 15, 2025 at 12:26:41PM +0100, Mark Brown wrote:
>On Thu, Sep 11, 2025 at 03:57:30PM -0400, Sasha Levin wrote:
>
>> We've started[1] the workflows@ list (which is how I stumbled on this thread)
>> about 5-6 years ago when the concern from multiple maintainers was that we all
>> have our magical scripts, they are seriously ugly, and everyone are ashamed of
>> sharing them. So this list was an effort to get the ball rolling on folks
>> sharing some of those ugly workflows and scripts in an attempt to standardize
>> and improve our processes.
>
>> I've shared this very hacky b4-dig script as exactly that: I have a very ugly
>> bash script that addresses some of the issues Linus brought up around being
>> able to find more context for a given patch/mail.  I use that script often, it
>> helps me spend less time on browsing lore (no, dfn: won't find you syzbot
>> reports or CI failures), and it just "works for me".
>
>This seems like a great example of a situation where the suggestions
>from one of the other thread of asking people to clearly mark when patch
>submissions are using these tools would have helped - had the submission
>described the above then the Python level review would've gone a lot
>differently I think.  Realising during review is a totally different
>experience to being told up front.

Do you mean using the Assisted-by tags that were discussed in the other thread?

-- 
Thanks,
Sasha

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 A8ED92FABEF;
	Mon, 15 Sep 2025 12:03:50 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1757937830; cv=none; b=VuDu38qt/R6aFvmjqRcBaGTZbH0FV4V/WP408csjwu9Mk/LoCFN5ha/2Ipo/BDWj/dwpNHaLzo1NusNuWdZCKy/a8sQjSzp/RmnpMxxu9KryDgZtxGMe0x07Zp5pt+LDbizcoeaUbzudbgtp2HEvDatQptBEiy1Ho7tjHV2PSR0=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1757937830; c=relaxed/simple;
	bh=k++F5CAnc5g3Ke5opUQkU/3F3JLhh0WCAWPms5P8Om0=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=jP/fieGuOyaVpO0NXpBhQ85OUXumuf29BjqODTU6UtYTMasU3sRfzEAUh6YJcZt6O9DSH1jpifWvXorJa5QQQmu9r6IyyPSWwmqxtovtl3vLIyFdgMDxn9P/Hdsy4bvSckj3El9r5ylplq/5k9XN6CxPylXCQonWyKeye2A4abk=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BjK1TvwJ; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BjK1TvwJ"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7FEB5C4CEF5;
	Mon, 15 Sep 2025 12:03:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1757937830;
	bh=k++F5CAnc5g3Ke5opUQkU/3F3JLhh0WCAWPms5P8Om0=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=BjK1TvwJ+wyY58MvtUMxZD0VBOgaGRxi1P3W1hlacdyaHFtOSn/KFnTDbEI2MVAz4
	 oI9MTguN+8VYq6LGtQP60F189sESCCZr4BF+7q0g/wvcklYiijaLT3JCnY3yj6uRCu
	 NIq7Yc0eOKc6IJ4qnegf96OuWpVvk/ObRoNR5GxqIpoOk454VFTP0Gcqr3bwFnIFAS
	 aALRSLVRAz8YvqmTtH58dXS50b5az+vfJU96UIHPvvFY/8CYoUUwsVxsRMkzYjNJNV
	 VA8JV5YmDZH2qRwxy82BEe4ev9Gq4Fr6YHoCCaiMykJk3dU778rEGeAb0WZkX+99KA
	 Lhs6oECiJw2hw==
Date: Mon, 15 Sep 2025 13:03:45 +0100
From: Mark Brown <broonie@kernel.org>
To: Sasha Levin <sashal@kernel.org>
Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>,
	konstantin@linuxfoundation.org, axboe@kernel.dk,
	csander@purestorage.com, io-uring@vger.kernel.org,
	torvalds@linux-foundation.org, workflows@vger.kernel.org,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [RFC] b4 dig: Add AI-powered email relationship discovery command
Message-ID: <8250c70a-0cab-4549-ad1f-aca28e7a1342@sirena.org.uk>
References: <20250905-sparkling-stalwart-galago-8a87e0@lemur>
 <4764751.e9J7NaK4W3@workhorse>
 <aMLlMz_ujgditm4c@laps>
 <4278380.jE0xQCEvom@workhorse>
 <aMMpqojURAZa7cPU@laps>
 <6e25b2e7-67a2-4a92-95d5-adb279e811a7@sirena.org.uk>
 <aMf9FaDxGY4nYI2f@laps>
Precedence: bulk
X-Mailing-List: io-uring@vger.kernel.org
List-Id: <io-uring.vger.kernel.org>
List-Subscribe: <mailto:io-uring+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:io-uring+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="kiyxGJ+4hswg2nI0"
Content-Disposition: inline
In-Reply-To: <aMf9FaDxGY4nYI2f@laps>
X-Cookie: Use a pun, go to jail.


--kiyxGJ+4hswg2nI0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Sep 15, 2025 at 07:48:37AM -0400, Sasha Levin wrote:
> On Mon, Sep 15, 2025 at 12:26:41PM +0100, Mark Brown wrote:

> > This seems like a great example of a situation where the suggestions
> > from one of the other thread of asking people to clearly mark when patch
> > submissions are using these tools would have helped - had the submission
> > described the above then the Python level review would've gone a lot
> > differently I think.  Realising during review is a totally different
> > experience to being told up front.

> Do you mean using the Assisted-by tags that were discussed in the other thread?

Not just that, which you did have, but also a mention of how the tools
have been used.

--kiyxGJ+4hswg2nI0
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmjIAKAACgkQJNaLcl1U
h9CGUwf+K1boklZhxyZRX+imuHacTwVekbiORc8Dxzu60q26HqKWVnc5UXRbvE2r
BYokhuc54XTEkz0N/DquoqGrMEz3U5m430SMNcsk/Z9zCCpeuYBR1J3y4Nr7I20I
qJZ7uW3Dl//9SfLPe5cxmILuTFG6902I5U9W4V6RGF1tF5OzrrioXzdAIiyDZHiL
k3M5UUMgGun2mTVaQXbTlVB8+NBn2EHuS/XYamCHh+XAxbh8mQhgsyneVa3aENyn
iT3+uzfplXy+icX1bbMunCAlHFhuHMxcJ5nmsyIDPOmVy3imsXV7YeZtCyxDOb2T
TpJzxmPoawUmnrrt2d2RMGJdjvUuGA==
=VKhj
-----END PGP SIGNATURE-----

--kiyxGJ+4hswg2nI0--

