Hello, Den 2026-05-26 kl. 14:06, skrev w15303746062: > > Hi Sasha, > >> Looking at the five commits: >> >> - 1/5 (74afeb812850) is the one that actually fixes the ABBA >> deadlock you observed under Syzkaller; it adds the generic vblank >> timer that replaces the open-coded vkms hrtimer path. >> >> - 2/5 (d54dbb5963bd) adds new CRTC helpers for "simple use cases". >> No Fixes:/Cc:stable, no described bug. >> >> - 3/5 (02e2681ffe1a) is a refactor that converts vkms to the new >> helpers. No Fixes:/Cc:stable, no described bug. >> >> - 4/5 (79ae8510b5b8) is a v7.1-rc1 timeout bump that depends on 1/5. >> It is not yet in any released stable, so applying it to 6.18.y >> would put it on an LTS before any LTS contains it. >> >> - 5/5 (3946d3ba9934) is a doc fix for 1/5. >> >> Per stable-kernel-rules, what I need to queue is the minimum set that >> fixes the bug. Could you explain, per patch, why 2/5..5/5 are required >> to make 1/5 work / are required to actually fix the deadlock? If only >> 1/5 is needed, please resend just that one with your Signed-off-by >> added (the carried patches today only have Thomas's S-o-b, which >> breaks the chain of custody on a stable submission). > > Thanks for the quick review and for pointing out the missing Signed-off-by. I > apologize for that omission; it was my mistake during the cherry-pick process. > > Regarding the dependency chain, I would like to clarify why commit 1/5 alone > cannot fix the issue: > > Commits 1/5 and 2/5 introduce the new generic vblank timer infrastructure to > the DRM core but do *not* touch the vkms driver at all. > Commit 3/5 (02e2681ffe1a) is the actual fix that modifies > `drivers/gpu/drm/vkms/vkms_crtc.c`. It removes the buggy open-coded hrtimer > that causes the ABBA deadlock and switches vkms to use the new infrastructure > introduced in 1/5 and 2/5. > > Therefore, 1/5, 2/5, and 3/5 form an indivisible set. Applying only 1/5 would > leave the deadlock in vkms completely unpatched. > > As for 4/5 and 5/5 (the timeout bump and doc fix), Maarten Lankhorst (DRM > maintainer) explicitly recommended pulling in this exact 5-commit list as the > proper upstream fix for this specific vkms issue (see the mailing list link > in this thread). > > However, if you feel 4/5 and 5/5 introduce unnecessary risk for the 6.18.y > stable tree, I can absolutely drop them and only submit 1/5, 2/5, and 3/5. > > I am preparing a v2 patch series now with my Signed-off-by added to the chain > of custody. Could you let me know if you prefer the full 5-patch series as > recommended by DRM maintainers, or just the minimal 3-patch series? > > Best regards, > Mingyu
5/5 might strictly speaking not be needed as it's a documentation fix and I have no idea of the policy about those. The reporter made a bug report of an ABBA deadlock that was fixed in upstream by the first 4 patches, perhaps it's good to those attach here to this discussion. Kind regards, ~Maarten Lankhorst
