linux-kernel - Re: [PATCH] drm/virtio: remove some redundant code

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] [day] [month] [year] [list]

Message-ID: <5194f82f-12d6-05aa-33b7-69c88923e455@nfschina.com>
Date:   Wed, 12 Jul 2023 18:15:09 +0800
From:   Su Hui <suhui@...china.com>
To:     Dan Carpenter <dan.carpenter@...aro.org>
Cc:     airlied@...hat.com, kraxel@...hat.com, gurchetansingh@...omium.org,
        olvaffe@...il.com, daniel@...ll.ch,
        dri-devel@...ts.freedesktop.org,
        virtualization@...ts.linux-foundation.org,
        linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org
Subject: Re: [PATCH] drm/virtio: remove some redundant code

On 2023/7/12 14:36, Dan Carpenter wrote:

> On Wed, Jul 12, 2023 at 09:18:42AM +0800, Su Hui wrote:
>> On 2023/7/11 19:13, Dan Carpenter wrote:
>>> On Tue, Jul 11, 2023 at 05:00:31PM +0800, Su Hui wrote:
>>>> virtio_gpu_get_vbuf always be successful,
>>>> so remove the error judgment.
>>>>
>>> No, just ignore the static checker false positive in this case.  The
>>> intent of the code is clear that if it did have an error it should
>>> return an error pointer.
>> Hi, Dan,
>>
>> Function "virtio_gpu_get_vbuf" call "kmem_cache_zalloc (vgdev->vbufs,
>> GFP_KERNEL | __GFP_NOFAIL)" to
>> allocate memory. Adding the " __GFP_NOFAIL”flag make sure it won't fail. And
>> "virtio_gpu_get_vbuf" never
>> return an error code, so I think this is not a false positive.
> We all see this and agree.
>
> However the check for if (IS_ERR()) is written deliberately because we
> might change the code to return error pointers in the future.  Static
> checkers are looking for code that does something unintentional but in
> this case the code was written that way deliberately.
Got it ,  I shouldn't remove it because the check may be useful in the 
future.
Thanks for your explanation.

Su Hui

>
> regards,
> dan carpenter
>