Re: [PATCH 2/2] agents: add a skill to determine Fixes tags

[Sasha Levin <sashal@kernel.org>]

On Sat, Oct 10, 2026 at 06:33:05AM -0400, Michael S. Tsirkin wrote:
>On Sat, Oct 10, 2026 at 11:40:56AM +0200, Thorsten Leemhuis wrote:
>> On 10/9/26 00:54, Sasha Levin wrote:
>> >
>> > +A ``Fixes:`` tag identifies the commit that introduced the bug being fixed. [...]
>>
>> Sorry for partly hijacking this, but it seems appropriate while we are
>> at it:
>>
>> What exactly is the right commit to specify when it comes to a
>> regression caused by a change that exposed a way older bug? The change
>> that exposed it? The change that introduced it in the first place? Both?
>> I'd tend to "both", but I guess some people might consider this as too
>> noisy.
>>
>> I've seen occasional discussions about this and our docs for humans are
>> a bit vague here:
>>
>> Documentation/process/submitting-patches.rst says:
>> ""If your patch fixes a bug in a specific commit, e.g. you found an
>> issue using git bisect, please use the ‘Fixes:’ tag with at least the
>> first 12 characters of the SHA-1 ID, and the one line summary.
>> [...]
>> A Fixes: tag indicates that the patch fixes a bug in a previous commit.
>> It is used to make it easy to determine where an issue originated""
>>
>> And Documentation/process/5.Posting.rst says:
>> ""One tag is used to refer to earlier commits which introduced problems
>> fixed by the patch:""
>>
>> Ciao, Thorsten
>
>I'd say the one exposed it. this way it is useful to answer
>the question "do i need this fix".

I'd suggest the original commit that introduced the issue, or if you really
want to - add two Fixes: tags.

My reasoning is that if there were holes around the reachability of the issue
in the past, we want to land the fix on all relevant trees, rather than just
the ones affected by the most recent case that enabled it to happen.

For example, let's say an issue was introduced in v6.5 and was reachable by one
codepath. Later, in v6.7, we refactored some code and made is issue benign by
removing the only codepath that could reach it. Even later, a new commit in
v7.0 made the issue reachable again.

If our Fixes: tag points to the v7.0 re-introduction, then we will miss the
backport to the v6.6 tree.

-- 
Thanks,
Sasha