On Wed, Jun 04, 2025 at 11:09:15AM -0400, Alex Deucher wrote: > On Wed, Jun 4, 2025 at 10:55 AM Uwe Kleine-König > <u.kleine-koe...@baylibre.com> wrote: > > > > Hello Alex, > > > > On Wed, Jun 04, 2025 at 03:29:58PM +0200, Greg KH wrote: > > > On Wed, Jun 04, 2025 at 09:15:14AM -0400, Alex Deucher wrote: > > > > On Wed, Jun 4, 2025 at 5:40 AM Uwe Kleine-König > > > > <u.kleine-koe...@baylibre.com> wrote: > > > > > On Fri, May 30, 2025 at 04:14:09PM -0400, Alex Deucher wrote: > > > > > > Already included in my -fixes PR for this week: > > > > > > https://lists.freedesktop.org/archives/amd-gfx/2025-May/125350.html > > > > > > > > > > Note the way this was done isn't maximally friendly to our stable > > > > > maintainers though. > > > > > > > > > > The commit in your tree (1b824eef269db44d068bbc0de74c94a8e8f9ce02) is > > > > > a > > > > > tad better than the patch that Aurabindo sent as it has: > > > > > > > > > > This reverts commit cfb2d41831ee5647a4ae0ea7c24971a92d5dfa0d > > > > > ... > > > > > > > > > > which at least is a known commit and has Cc: stable. > > > > > > > > > > However this is still a bit confusing as commit cfb2d41831ee has no > > > > > Cc: > > > > > stable, but a duplicate in mainline: f1c6be3999d2 that has Cc: stable. > > > > > > > > > > So f1c6be3999d2 was backported to 6.14.7 (commit > > > > > 4ec308a4104bc71a431c75cc9babf49303645617), 6.12.29 (commit > > > > > 468034a06a6e8043c5b50f9cd0cac730a6e497b5) and 6.6.91 (commit > > > > > c8a91debb020298c74bba0b9b6ed720fa98dc4a9). But it might not be obvious > > > > > that 1b824eef269db44d068bbc0de74c94a8e8f9ce02 needs backporting to > > > > > trees > > > > > that don't contain cfb2d41831ee (or a backport of it). > > > > > > > > > > Please keep an eye on that change that it gets properly backported. > > > > I'm not sure if my mail was already enough to ensure that > > 1b824eef269db44d068bbc0de74c94a8e8f9ce02 will be backported to stable, > > so that request still stands. > > > > > > DRM patches land in -next first since that is where the developers > > > > work and then bug fixes get cherry-picked to -fixes. When a patch is > > > > cherry-picked to -fixes, we use cherry-pick -x to keep the reference > > > > to the original commit and then add stable CC's as needed. See this > > > > thread for background: > > > > https://lore.kernel.org/dri-devel/871px5iwbx....@intel.com/T/#t > > > > Yeah I thought so. The problem isn't per se that there are duplicates, > > but that they are not handled with the needed care. I don't know about > > Greg's tooling, but my confusion would have been greatly reduced if you > > reverted f1c6be3999d2 instead of cfb2d41831ee. That is the older commit > > (with POV = mainline) and the one that has the relevant information (Cc: > > stable and the link to cfb2d41831ee). > > The revert cc'd stable so it should go to stable. You can check the > cherry-picked commits to see what patches they were cherry-picked from > to see if you need to apply them to stable kernels.
Yes, and I'd expect that the scripts used by stable maintainers looking
at 1b824eef269d will apply that to all stable branches that contain
cfb2d41831ee or a backport of it.
Given that that cfb2d41831ee wasn't backported to any stable kernel and
the commit itself will only be in 6.16-rc1 the set of kernels to
backport the revert to, will be the empty set.
(In git commands:
$ git log --oneline --source
stable/linux-{5.{4,10,15},6.{6,12,14,15}}.y
^1b824eef269db44d068bbc0de74c94a8e8f9ce02 --grep="commit
cfb2d41831ee5647a4ae0ea7c24971a92d5dfa0d upstream"
<void>
If however you look for cfb2d41831ee's twin, there is:
$ git log --oneline --source
stable/linux-{5.{4,10,15},6.{6,12,14,15}}.y
^1b824eef269db44d068bbc0de74c94a8e8f9ce02 --grep="commit
f1c6be3999d2be2673a51a9be0caf9348e254e52 upstream"
4ec308a4104b stable/linux-6.14.y drm/amd/display: more liberal
vmin/vmax update for freesync
468034a06a6e stable/linux-6.12.y drm/amd/display: more liberal
vmin/vmax update for freesync
c8a91debb020 stable/linux-6.6.y drm/amd/display: more liberal
vmin/vmax update for freesync
Having said that, I don't know how the stable scripts work, *maybe*
having mentioned cfb2d41831ee in f1c6be3999d2 is indeed good enough.)
So if you had reverted f1c6be3999d2 instead of cfb2d41831ee I
wouldn't have wailed and I guess Greg would be moderately happy, too.
> > Getting this wrong is just a big waste of time and patience (or if the
> > backport is missed results in systems breaking for problems that are
> > already known and fixed).
>
> Tons of patches end up getting cherry-picked to stable without anyone
> even asking for them via Sasha's scripts. Won't this cause the same
> problem?
No, the problem only arises if a patch is in mainline twice and one
variant is backported to stable and later the other one is reverted (or
otherwise fixed). Patches that get backported without Cc: stable are not
a problem.
Best regards
Uwe
signature.asc
Description: PGP signature
