On Wed, Jun 4, 2025 at 10:55 AM Uwe Kleine-König u.kleine-koenig@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-koenig@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.fsf@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.
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?
Alex