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@xxxxxxxxxxxxxxxxx/
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@xxxxxxxxx>
Reviewed-by: Matthew Brost <matthew.brost@xxxxxxxxx> # commit 1
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@xxxxxxxxx>
Cc: stable@xxxxxxxxxxxxxxx # 6.12+
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@xxxxxxxxx>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@xxxxxxxxx>
Link: https://patchwork.freedesktop.org/patch/msgid/20241220171919.571528-2-umesh.nerlige.ramappa@xxxxxxxxx
(cherry picked from commit 55039832f98c7e05f1cf9e0d8c12b2490abd0f16)
Signed-off-by: Thomas Hellström <thomas.hellstrom@xxxxxxxxxxxxxxx>
(cherry picked from commit f0ed39830e6064d62f9c5393505677a26569bb56)
"""
Where most of the git IDs in it are invalid right now :)
--
Thanks,
Sasha
