Re: [PATCH] drm/radeon: cleanup coding style a bit

[Christian KÃnig]

Am 30.04.20 um 13:00 schrieb Bernard:
> åääïJoe Perches <joe@xxxxxxxxxxx>
> åéææï2020-04-27 01:53:06
> æääï"Christian KÃnig" <christian.koenig@xxxxxxx>,Bernard Zhao <bernard@xxxxxxxx>,Alex Deucher <alexander.deucher@xxxxxxx>,"David (ChunMing) Zhou" <David1.Zhou@xxxxxxx>,David Airlie <airlied@xxxxxxxx>,Daniel Vetter <daniel@xxxxxxxx>,amd-gfx@xxxxxxxxxxxxxxxxxxxxx,dri-devel@xxxxxxxxxxxxxxxxxxxxx,linux-kernel@xxxxxxxxxxxxxxx
> æéäïopensource.kernel@xxxxxxxx
> äéïRe: [PATCH] drm/radeon: cleanup coding style a bit>On Sun, 2020-04-26 at 15:18 +0200, Christian KÃnig wrote:
> > > Am 26.04.20 um 15:12 schrieb Bernard Zhao:
> > > > Maybe no need to check ws before kmalloc, kmalloc will check
> > > > itself, kmalloc`s logic is if ptr is NULL, kmalloc will just
> > > > return
> > > >
> > > > Signed-off-by: Bernard Zhao <bernard@xxxxxxxx>
> > > Reviewed-by: Christian KÃnig <christian.koenig@xxxxxxx>
> > >
> > > I'm wondering why the automated scripts haven't found that one before.
> > because this pattern is
> >
> > 	if (foo)
> > 		kfree(bar);
> >
> > and the pattern looked for is:
> >
> > 	if (foo)
> > 		kfree(foo);
> >
> > > > diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
> > []
> > > > @@ -1211,8 +1211,7 @@ static int atom_execute_table_locked(struct atom_context *ctx, int index, uint32
> > > >    	SDEBUG("<<\n");
> > > >    
> > > >    free:
> > > > -	if (ws)
> > > > -		kfree(ectx.ws);
> > > > +	kfree(ectx.ws);
> > > >    	return ret;
> > > >    }
> > I'm wondering if this removal is correct as the function
> > is named _locked and it may be recursive or called under
> > some external lock.
> Hi
> I am a little confused about this. I understand that the caller guarantees the lock protection
> that we will not release the wrong pointer. And the NULL check is the same with the first check in kfree?
> Maybe we do not need check twich.

I don't understand the comment either. When you look at the function you 
see that code is freeing up the temporary allocated buffer which is to 
large for the stack.

In other words we kcalloc() this buffer a few lines above and free it 
here again. So I think the patch is perfectly valid.

What we could do is to update the coci pattern to catch this as well, 
but this case is so rare that it is probably not worth it.

Regards,
Christian.

> Regards,
> Bernard
>
>
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx