On 9/10/26 15:21, [email protected] wrote: > [Severity: High] > Does calling drm_crtc_commit_wait() here cause a kernel warning or potential > deadlock? > > According to the DRM Subsystem Details, drm_atomic_helper_commit_tail() > and its variants execute in atomic context where sleeping is forbidden.
Both findings rest on that premise, and it does not hold. The commit tail runs in process context: drm_atomic_helper_commit() calls commit_tail() on the caller's stack for a blocking commit and queues it on a workqueue for a nonblocking one. commit_tail() then calls drm_atomic_helper_wait_for_fences() and drm_atomic_helper_wait_for_dependencies() - three loops of drm_crtc_commit_wait(), the very function flagged here - immediately before the ->atomic_commit_tail hook. The default hooks block in drm_atomic_helper_wait_for_vblanks(), and the CRTC atomic_enable and atomic_disable helpers run inside them. The wait itself is what the core asks for. From the drm_private_obj documentation in drm_atomic.h: "Drivers should store (and get a reference to) the &drm_crtc_commit structure in our private state in &drm_mode_config_helper_funcs.atomic_commit_setup, and then wait for that commit to complete as the first step of &drm_mode_config_helper_funcs.atomic_commit_tail, similar to drm_atomic_helper_wait_for_dependencies()." vc4_atomic_commit_tail() does exactly that, followed by clk_set_min_rate(), which takes the same clk prepare_lock as clk_set_rate(). The wait is on the previous commits' drm_crtc_commit, never on the current one, so it cannot wait on itself. The pre-existing note answers itself: vop2_crtc_atomic_disable() is called from that same commit tail, and the @atomic_commit_tail documentation says "When disabling a CRTC this hook _must_ stall for the commit to complete." It also calls clk_set_parent() and clk_disable_unprepare() there, unchanged. I suspect the two senses of "atomic" got conflated: an atomic commit is an all-or-nothing modeset update, not in_atomic() context. There is no might_sleep() or context restriction on this path. Thanks, Igor
