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.