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: <ccd14dee-f275-5de4-b5c1-4f359d155288@amd.com>
Date:   Tue, 21 Apr 2020 11:48:23 +0200
From:   Christian König <christian.koenig@....com>
To:     赵军奎 <bernard@...o.com>
Cc:     Felix Kuehling <Felix.Kuehling@....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,
        opensource.kernel@...o.com, Elfring <Markus.Elfring@....de>
Subject: Re: [PATCH V3] amdgpu: remove unnecessary condition check

Am 21.04.20 um 10:44 schrieb 赵军奎:
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>>> index 9dff792c9290..5424bd921a7b 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>>> @@ -660,13 +660,12 @@ static int reserve_bo_and_vm(struct kgd_mem *mem,
>>>    
>>>    	ret = ttm_eu_reserve_buffers(&ctx->ticket, &ctx->list,
>>>    				     false, &ctx->duplicates);
>>> -	if (!ret)
>>> -		ctx->reserved = true;
>>> -	else {
>>> -		pr_err("Failed to reserve buffers in ttm\n");
>>> +	if (ret) {
>>> +		pr_err("Failed to reserve buffers in ttm.\n");
>>>    		kfree(ctx->vm_pd);
>>>    		ctx->vm_pd = NULL;
>>> -	}
>>> +	} else
>>> +		ctx->reserved = true;
>> That is still not correct coding style. In general when one branch of an
>> if/else uses {} the other one should use it as well.
>>
>> But I agree with Felix that this change looks rather superfluous to me
>> as well.
>>
>> Regards,
>> Christian.
> About the code style, you are right, I checked the refers:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Ftree%2FDocumentation%2Fprocess%2Fcoding-style.rst%3Fid%3D90280eaa88ac1a9140dc759941123530d5545bb6%23n191&amp;data=02%7C01%7Cchristian.koenig%40amd.com%7C3640a853a31e4e98f66d08d7e5d05300%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637230555230917911&amp;sdata=Ihum8tjQAw%2Bk67KTq%2B3zBBLHL1bSHBhBhSyG0jWeMcE%3D&amp;reserved=0
> The if and else should use the same style.
> But i have to say there are so many code not follow the kernel code-style in amdgpu module.
> And also the ./scripts/checkpatch.pl did not throw any warning or error.

That is unfortunately true, yes. But we try to push new code through the 
usual code review and improve things as we go.

On the other hand patches just to fix the coding style are usually seen 
as an unnecessary interruption and just a waste of time.

But in this particular case you could argue that the original code is 
not easily readable and you try to improve that.

> If this change looks rather superfluous to all of you, should i change to the V1 change?
> After all i don`t think there is any necessary to check "ret" again, merge the <else and if (ret)>
> maybe better.
> Original code:
> static int reserve_bo_and_cond_vms(struct kgd_mem *mem,.....
> 	if (!ret)
> 		ctx->reserved = true;
> 	else
> 		pr_err("Failed to reserve buffers in ttm.\n");
>
> 	if (ret) {
> 		kfree(ctx->vm_pd);
> 		ctx->vm_pd = NULL;
> 	}

In general I suggest to use the following pattern for this error 
handling and avoid the else branch altogether:

if (ret) {
     pr_err("Failed to reserve buffers in ttm.\n");
     kfree(ctx->vm_pd);
     ctx->vm_pd = NULL;
     return ret;
}

ctx->reserved = true;
return 0;

When things become more complex good practice is to insert a "goto 
error_cleanup"; instead of in place cleanup.

Regards,
Christian.

>
> BR//bernard

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ