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. > > 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
