Re: [PATCH v3 2/2] drm/amdgpu: Fix lockdep false positive in amdgpu_lockdep_init

Mikhail Gavrilov <[email protected]> Thu, 30 Jul 2026 19:48:46 +0500
Newsgroups org.freedesktop.lists.amd-gfx,org.kernel.vger.stable
Message-ID <CABXGCsPXb9zZA3U8XmPsx_Es8E_6M4w8SBNUC1_oQ_Qig1hYpg@mail.gmail.com>
On Thu, Jul 30, 2026 at 5:35 PM Arunpravin Paneer Selvam
<[email protected]> wrote:
>
> 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]>

You are right, and it goes a bit further: the class is registered before any
module init runs. Every GFP_KERNEL allocation goes through might_alloc(), which
does exactly this fs_reclaim_acquire()/fs_reclaim_release() pair, so the class
is registered on the first such allocation in early boot. Registration is
idempotent and its order carries no meaning for lockdep (only edges do), so the
pair here adds nothing.

So it is a no-op and dropping it is functionally identical. Data point: my
original patch did exactly that, and with the pair removed the reproducer no
longer triggers the splat and lockdep stays active for the whole boot.

Keeping it does look deliberate rather than accidental, though: in the v1
thread Christian asked for the annotation to be moved outside the notifier lock
rather than removed, and mentioned pending work on the VM eviction lock which
has a similar fs_reclaim ordering problem. So whether to drop it is a call for
Christian and Vitaly rather than a technical question.

-- 
Best Regards,
Mike Gavrilov.