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);