AAARRRGGGHHH!!!! (was Re: [PATCH 6.12.y] xe/oa: Fix query mode of operation for OAR/OAC)

[Sasha Levin]

On Wed, Jan 15, 2025 at 12:15:46PM +0100, Simona Vetter wrote:
>On Wed, Jan 15, 2025 at 10:38:34AM +0100, Greg KH wrote:
>So my understanding is that you got confused by this:
>
>> commit 55039832f98c7e05f1cf9e0d8c12b2490abd0f16 upstream
>
>$ git log --grep="(cherry picked from commit 55039832f98c7e05f1cf9e0d8c12b2490abd0f16)" --since="6 month ago"   --pretty=oneline
>f0ed39830e6064d62f9c5393505677a26569bb56
>
>And yes f0ed39830e6064d62f9c5393505677a26569bb56 is the commit you care
>about for stable backport and cve tracking purposes, because it's the one
>in v6.13-rc6.
>
>And the thing is, Sasha's bot found that one too:
>
>https://lore.kernel.org/all/20250110164811-61a12d6905bb8676@stable.kernel.org/
>
>Except Sasha's bot plays guessing games, the above git log query is exact.

Cool, can we test it out? I'll try and pick a recent commit (2024).

Let's assume that I'm looking at the v6.10 git tree before 50aec9665e0b
("drm/xe: Use ordered WQ for G2H handler") made it upstream ("git
checkout v6.10" will do the trick), and I get a backport request that
says:

	commit 50aec9665e0babd62b9eee4e613d9a1ef8d2b7de upstream

I run my trusty script that says "50aec9665e0b isn't real, grep for
cherry picked from line!". My trusty script runs the query you've
provided:

$ git log --grep="(cherry picked from commit 50aec9665e0babd62b9eee4e613d9a1ef8d2b7de)" --since="6 month ago"   --pretty=oneline
2d9c72f676e6f79a021b74c6c1c88235e7d5b722 drm/xe: Use ordered WQ for G2H handler
c002bfe644a29ba600c571f2abba13a155a12dcd drm/xe: Use ordered WQ for G2H handler

Which commit do I pick? Note that they are slightly different from
eachother, and c002bfe644 landed in v6.9 while 2d9c72f676 landed in
v6.10.

>Like I tried to explain in my reply to Sasha somewhere else in this thread
>it really only takes two things:
>- drm maintainers consistently add cherry picked from lines anytime we
>  cherry-pick
>- you adjust your script to go hunt for the cherry pick alias if you get a
>  sha1 that makes no sense, so that you can put in the right sha1. And if
>  you do that for any sha1 you find (whether upstream references, Fixes:
>  or Reverts or stable candidate commits or whatever really), it will sort
>  out all the things we've been shouting about for years now.

We still have holes here... For example, this backport claims to:

	Fixes: 8135f1c09dd2 ("drm/xe/oa: Don't reset OAC_CONTEXT_ENABLE on OA stream close")

But 8135f1c09dd2 is a cherry-pick:

	(cherry picked from commit 0c8650b09a365f4a31fca1d1d1e9d99c56071128)

In the future, if we get a new patch that says:

	Fixes: 0c8650b09a36 ("drm/xe/oa: Don't reset OAC_CONTEXT_ENABLE on OA stream close")

By your logic, our scripts will look at it and say "0c8650b09a36 is a
real commit, but it's not in linux-6.12.y so there's no need to backport
the fix".

Which is the wrong thing to do, because we have 8135f1c09dd2 in
linux-6.12.y.

So no, this isn't a simple trace-the-cherry-pick-tags exercise.

>  Automatically, without human intervention, because it's just a git
>  oneliner.

So look at the backport in question which started this thread. The
backporter ends up with:

"""
[...]

commit 55039832f98c7e05f1cf9e0d8c12b2490abd0f16 upstream

[...]

Fixes: 8135f1c09dd2 ("drm/xe/oa: Don't reset OAC_CONTEXT_ENABLE on OA stream close")
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa at intel.com>
Reviewed-by: Matthew Brost <matthew.brost at intel.com> # commit 1
Reviewed-by: Ashutosh Dixit <ashutosh.dixit at intel.com>
Cc: stable at vger.kernel.org # 6.12+
Reviewed-by: Jonathan Cavitt <jonathan.cavitt at intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit at intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241220171919.571528-2-umesh.nerlige.ramappa@intel.com
(cherry picked from commit 55039832f98c7e05f1cf9e0d8c12b2490abd0f16)
Signed-off-by: Thomas Hellström <thomas.hellstrom at linux.intel.com>
(cherry picked from commit f0ed39830e6064d62f9c5393505677a26569bb56)

"""

Where most of the git IDs in it are invalid right now :)

-- 
Thanks,
Sasha