Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Encoder atomic disable callback calls a sleeping function, violating atomic context rules. -- --- Patch [6]: [PATCH v2 6/6] drm/nouveau/kms/nv50-: Obliterate nouveau_encoder->crtc --- commit 9b6ea3488cdb59d28deb854dd17d63d4b20e1a27 Author: Lyude Paul <[email protected]> drm/nouveau/kms/nv50-: Obliterate nouveau_encoder->crtc This commit removes the nouveau_encoder->crtc tracking artifact from the pre-atomic modesetting days. It relies entirely on the atomic state to track the assigned CRTC, as all redundant legacy tracking users have been removed. > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c > b/drivers/gpu/drm/nouveau/dispnv50/disp.c > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c > +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c [ ... ] > @@ -1634,7 +1631,6 @@ nv50_sor_atomic_disable(struct drm_encoder *encoder, > struct drm_atomic_commit *s > > nv_encoder->update(nv_encoder, head->base.index, NULL, 0, 0); > nv50_audio_disable(encoder, &head->base); [Severity: High] This is a pre-existing issue, but I noticed a potential sleep-in-atomic bug in this execution path. The nv50_sor_atomic_disable() function is an encoder atomic disable callback, which runs in an atomic context during non-blocking commits. It explicitly calls nv50_audio_disable(): nv50_sor_atomic_disable() nv50_audio_disable(encoder, &head->base); Looking at nv50_audio_disable(), it acquires a mutex: nv50_audio_disable() mutex_lock(&drm->audio.lock); Can this cause system instability or kernel warnings by calling a sleeping function (mutex_lock) from an atomic context? > - nv_encoder->crtc = NULL; > } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=6
