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
