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>] [day] [month] [year] [list]
Message-ID: <446a2a2a-155b-1fe3-44f3-89033b80ad34@gmx.de>
Date:   Thu, 25 May 2023 19:39:15 +0200
From:   Helge Deller <deller@....de>
To:     Markus Elfring <Markus.Elfring@....de>,
        kernel-janitors@...r.kernel.org, linux-fbdev@...r.kernel.org,
        dri-devel@...ts.freedesktop.org,
        Javier Martinez Canillas <javierm@...hat.com>,
        Michal Koutný <mkoutny@...e.com>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Zheng Wang <zyytlz.wz@....com>
Cc:     LKML <linux-kernel@...r.kernel.org>, cocci@...ia.fr,
        1395428693sheep@...il.com, alex000young@...il.com,
        hackerzheng666@...il.com
Subject: Re: [PATCH 1/4] fbdev: imsttfb: Fix error handling in init_imstt()

On 5/25/23 07:33, Markus Elfring wrote:
>>> The return value was overlooked from a call of
>>> the function “fb_alloc_cmap”.
>>>
>>> * Thus use a corresponding error check.
>>>
>>> * Add two jump targets so that a bit of exception handling
>>>     can be better reused at the end of this function.
> …
>>> +++ b/drivers/video/fbdev/imsttfb.c
> …
>>> @@ -1452,17 +1452,25 @@ static int init_imstt(struct fb_info *info)
>>>                      FBINFO_HWACCEL_FILLRECT |
>>>                      FBINFO_HWACCEL_YPAN;
>>>
>>> -    fb_alloc_cmap(&info->cmap, 0, 0);
>>> +    ret = fb_alloc_cmap(&info->cmap, 0, 0);
>>> +    if (ret)
>>> +        goto release_framebuffer;
>>>
>>>        if (register_framebuffer(info) < 0) {
>>> -        framebuffer_release(info);
>>> -        return -ENODEV;
>>> +        fb_dealloc_cmap(&info->cmap);
>>> +        goto e_nodev;
>>>        }
>>>
>>>        tmp = (read_reg_le32(par->dc_regs, SSTATUS) & 0x0f00) >> 8;
>>>        fb_info(info, "%s frame buffer; %uMB vram; chip version %u\n",
>>>            info->fix.id, info->fix.smem_len >> 20, tmp);
>>>        return 0;
>>> +
>>> +e_nodev:
>>> +    ret = -ENODEV;
>>
>> I think the return value isn't checked at all, so you could
>> simply return below "-ENODEV" for all cases (instead of "return ret").
>> Then you don't need the e_nodev label and can simplify the flow.
>
> Can it be helpful to distinguish involved error codes better?

No.

Helge

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ