Re: [PATCH v3 2/2] drm/amdgpu: Fix lockdep false positive in amdgpu_lockdep_init
Arunpravin Paneer Selvam <[email protected]> Thu, 30 Jul 2026 18:05:06 +0530
| Newsgroups | org.freedesktop.lists.amd-gfx,org.kernel.vger.stable |
|---|---|
| Message-ID | <[email protected]> |
On 7/24/2026 3:48 AM, [email protected] wrote: > From: Vitaly Prosyak <[email protected]> > > Move fs_reclaim_acquire() to before all lock acquisitions to eliminate > false positive circular locking dependency warning. > > This is a 7.2-cycle regression fix suitable for stable backport. > > v3: Address Mikhail Gavrilov technical review: > - Clarify that fs_reclaim_acquire/release pair only REGISTERS the > fs_reclaim lock class, does NOT create a static edge when called > with no locks held > - Explain that the actual fs_reclaim -> notifier_lock edge is > established at runtime during memory reclaim -> MMU notifier path > - Add Cc: Arunpravin PaneerSelvam > > v2: Address Mikhail Gavrilov review feedback: > - Fix author name: Michael -> Mikhail Gavrilov in all trailers > - Add Fixes: tag to link regression to original commit > - Add Tested-by: Mikhail Gavrilov (tested on RX 7900 XTX) > > Fixes: 1d0f5838b126 ("drm/amdgpu: Add lockdep annotations for lock ordering validation") > Reported-by: Mikhail Gavrilov <[email protected]> > Analyzed-by: Mikhail Gavrilov <[email protected]> > Test-case-by: Mikhail Gavrilov <[email protected]> > Tested-by: Mikhail Gavrilov <[email protected]> > Suggested-by: Christian König <[email protected]> > Tested-by: Vitaly Prosyak <[email protected]> > Cc: Christian König <[email protected]> > Cc: Alex Deucher <[email protected]> > Cc: Arunpravin PaneerSelvam <[email protected]> > Cc: [email protected] > Signed-off-by: Vitaly Prosyak <[email protected]> > Change-Id: I3f1a19877615cefc2e5d7c063144a6404a96ba38 > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_lockdep.c | 21 ++++++++++++++------- > 1 file changed, 14 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_lockdep.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_lockdep.c > index b251350b1fb2..5f1f1960ef72 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_lockdep.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_lockdep.c > @@ -151,6 +151,20 @@ int amdgpu_lockdep_init(void) > * This establishes the dependency chain. > */ > > + /* > + * Register fs_reclaim lock class FIRST, before taking any locks. > + * > + * This acquire/release pair does NOT create a static lockdep edge > + * (no locks are held between acquire and release). It only registers > + * the fs_reclaim lock class with lockdep. > + * > + * The actual fs_reclaim -> notifier_lock dependency is established at > + * RUNTIME when memory reclaim invokes MMU notifiers: > + * fs_reclaim (held by reclaim) -> notifier_lock (acquired in callback) > + */ > + fs_reclaim_acquire(GFP_KERNEL); > + fs_reclaim_release(GFP_KERNEL); The fs_reclaim class is already registered by the core kernel on the first GFP_KERNEL allocation, well before amdgpu_lockdep_init() runs. Is it kept on purpose, or can it be dropped?. Otherwise: Acked-by: Arunpravin Paneer Selvam <[email protected]> > + > /* Level 1: Global userq scheduler mutex (outermost) */ > mutex_lock(&locks->userq_sch_mutex); > > @@ -168,12 +182,6 @@ int amdgpu_lockdep_init(void) > > /* Level 7: DRM file list mutex */ > mutex_lock(&locks->filelist_mutex); > - /* > - * Mark potential memory reclaim boundary. > - * GPU operations might trigger memory allocation/reclaim. > - */ > - fs_reclaim_acquire(GFP_KERNEL); > - > /* Level 8: SRBM register access */ > mutex_lock(&locks->srbm_mutex); > /* Level 9: GRBM index access */ > @@ -190,7 +198,6 @@ int amdgpu_lockdep_init(void) > spin_unlock_irqrestore(&locks->mmio_idx_lock, flags); > mutex_unlock(&locks->grbm_idx_mutex); > mutex_unlock(&locks->srbm_mutex); > - fs_reclaim_release(GFP_KERNEL); > > mutex_unlock(&locks->filelist_mutex); > mutex_unlock(&locks->reset_lock);