Re: [PATCH AUTOSEL 6.0 38/44] drm/amdgpu: Unlock bo_list_mutex after error handling

[Sasha Levin]

On Mon, Nov 21, 2022 at 12:07:40PM +0100, Christian König wrote:
> Am 21.11.22 um 10:57 schrieb Michel Dänzer:
> > On 11/19/22 03:11, Sasha Levin wrote:
> > > From: Philip Yang <Philip.Yang@xxxxxxx>
> > >
> > > [ Upstream commit 64f65135c41a75f933d3bca236417ad8e9eb75de ]
> > >
> > > Get below kernel WARNING backtrace when pressing ctrl-C to kill kfdtest
> > > application.
> > >
> > > If amdgpu_cs_parser_bos returns error after taking bo_list_mutex, as
> > > caller amdgpu_cs_ioctl will not unlock bo_list_mutex, this generates the
> > > kernel WARNING.
> > >
> > > Add unlock bo_list_mutex after amdgpu_cs_parser_bos error handling to
> > > cleanup bo_list userptr bo.
> > >
> > >  WARNING: kfdtest/2930 still has locks held!
> > >  1 lock held by kfdtest/2930:
> > >   (&list->bo_list_mutex){+.+.}-{3:3}, at: amdgpu_cs_ioctl+0xce5/0x1f10 [amdgpu]
> > >   stack backtrace:
> > >    dump_stack_lvl+0x44/0x57
> > >    get_signal+0x79f/0xd00
> > >    arch_do_signal_or_restart+0x36/0x7b0
> > >    exit_to_user_mode_prepare+0xfd/0x1b0
> > >    syscall_exit_to_user_mode+0x19/0x40
> > >    do_syscall_64+0x40/0x80
> > >
> > > Signed-off-by: Philip Yang <Philip.Yang@xxxxxxx>
> > > Reviewed-by: Christian König <christian.koenig@xxxxxxx>
> > > Signed-off-by: Alex Deucher <alexander.deucher@xxxxxxx>
> > > Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
> > > ---
> > >  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > > index b7bae833c804..9d59f83c8faa 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > > @@ -655,6 +655,7 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser *p,
> > >  		}
> > >  		mutex_unlock(&p->bo_list->bo_list_mutex);
> > >  	}
> > > +	mutex_unlock(&p->bo_list->bo_list_mutex);
> > >  	return r;
> > >  }
> > Looks doubtful that this is a correct backport — there's an identical mutex_unlock call just above.
>
>
> Oh, yes good point. This patch doesn't needs to be backported at all 
> because it just fixes a problem introduced in the same cycle:

Dropping it, thanks!

--
Thanks,
Sasha