Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] The `reset_ctl.reset_lock` mutex is left uninitialized after the removal of its `mutex_init()` call, leading to a crash or lockdep splat when `mutex_lock()` is subsequently called on it. --
commit 6434ae76184d0a8413780553647c7fd53034416b Author: Arnd Bergmann <[email protected]> amdgpu: lockdep: move temporary mutexes off stack This commit changes the dummy locks in amdgpu_lockdep_init() to use static allocation instead of stack allocation to reduce the stack frame size. It removes the explicit mutex_init() calls for these locks. > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_lockdep.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_lockdep.c > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_lockdep.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_lockdep.c > @@ -85,13 +85,13 @@ int amdgpu_lockdep_init(void) > { > struct amdgpu_reset_domain *reset_domain = NULL; > struct amdgpu_reset_control reset_ctl; [ ... ] > @@ -102,16 +102,6 @@ int amdgpu_lockdep_init(void) > if (!reset_domain) > return -ENOMEM; > > - /* Initialize dummy locks */ > - mutex_init(&userq_sch_mutex); > - mutex_init(&userq_mutex); > - mutex_init(¬ifier_lock); > - mutex_init(&vram_lock); > - mutex_init(&reset_ctl.reset_lock); [Severity: High] With this initialization removed, does reset_ctl.reset_lock remain uninitialized? Since reset_ctl is still allocated on the stack earlier in the function, calling mutex_lock(&reset_ctl.reset_lock) later in this routine will operate on uninitialized memory. Could this trigger a crash or lockdep splat? > - mutex_init(&srbm_mutex); > - mutex_init(&grbm_idx_mutex); > - spin_lock_init(&mmio_idx_lock); -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
