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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ae65a955251bd43ac71b7a162320bbc1fe220a67.camel@perches.com>
Date:   Sun, 26 Apr 2020 10:53:06 -0700
From:   Joe Perches <joe@...ches.com>
To:     Christian König <christian.koenig@....com>,
        Bernard Zhao <bernard@...o.com>,
        Alex Deucher <alexander.deucher@....com>,
        "David (ChunMing) Zhou" <David1.Zhou@....com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>, amd-gfx@...ts.freedesktop.org,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Cc:     opensource.kernel@...o.com
Subject: 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@...o.com>
> 
> Reviewed-by: Christian König <christian.koenig@....com>
> 
> 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.