Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Low] Early return on dma_resv_alloc() failure unintentionally skips unrelated lockdep annotations. --
commit 2c2f2285d05d44caf485778222c036bce79fbb3f Author: Christian König <[email protected]> drm/xe: Use dma_resv_alloc for lockdep annotation This patch replaces the stack-allocated dma_resv in xe_pm_runtime_lockdep_prime() with a dynamically allocated one to align with the move towards reference-counted dynamic allocation. > diff --git a/drivers/gpu/drm/xe/xe_pm.c b/drivers/gpu/drm/xe/xe_pm.c > index a5289a9df8d25..13f25d15f5482 100644 > --- a/drivers/gpu/drm/xe/xe_pm.c > +++ b/drivers/gpu/drm/xe/xe_pm.c > @@ -764,15 +764,20 @@ static void xe_rpm_might_enter_cb(const struct > xe_device *xe) > */ > static void xe_pm_runtime_lockdep_prime(void) > { > - struct dma_resv lockdep_resv; > + struct dma_resv *lockdep_resv; > + > + lockdep_resv = dma_resv_alloc(); > + if (!lockdep_resv) > + return; [Severity: Low] Does this unconditional early return unintentionally skip the unrelated lockdep annotations that follow? If dma_resv_alloc() fails, it looks like we abort the entire xe_pm_runtime_lockdep_prime() function. This skips the completely independent shrinker and nod3cold annotations below. Could this lead to incomplete lockdep coverage under memory pressure? > > - dma_resv_init(&lockdep_resv); > lock_map_acquire(&xe_pm_runtime_d3cold_map); > /* D3Cold takes the dma_resv locks to evict bos */ > - dma_resv_lock(&lockdep_resv, NULL); > - dma_resv_unlock(&lockdep_resv); > + dma_resv_lock(lockdep_resv, NULL); > + dma_resv_unlock(lockdep_resv); > lock_map_release(&xe_pm_runtime_d3cold_map); > > + dma_resv_put(lockdep_resv); > + > /* Shrinkers might like to wake up the device under reclaim. */ > fs_reclaim_acquire(GFP_KERNEL); > lock_map_acquire(&xe_pm_runtime_nod3cold_map); -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=7
