[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75VeSYesZuJ-NEfEAvaRepEUtdLmxGrYmthD1YkSg-bsK_g@mail.gmail.com>
Date: Sat, 28 Jun 2025 22:58:20 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Abdun Nihaal <abdun.nihaal@...il.com>
Cc: andy@...nel.org, dan.carpenter@...aro.org, gregkh@...uxfoundation.org,
lorenzo.stoakes@...cle.com, tzimmermann@...e.de, riyandhiman14@...il.com,
willy@...radead.org, notro@...nnes.org, thomas.petazzoni@...e-electrons.com,
dri-devel@...ts.freedesktop.org, linux-fbdev@...r.kernel.org,
linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org,
Andy Shevchenko <andriy.shevchenko@...el.com>
Subject: Re: [PATCH v2 2/2] staging: fbtft: cleanup error handling in fbtft_framebuffer_alloc()
On Sat, Jun 28, 2025 at 7:59 AM Abdun Nihaal <abdun.nihaal@...il.com> wrote:
>
> The error handling in fbtft_framebuffer_alloc() mixes managed allocation
> and plain allocation, and performs error handling in an order different
> from the order in fbtft_framebuffer_release().
>
> Fix them by moving vmem allocation closer to where it is used, and using
> plain kzalloc() for txbuf allocation.
...
> + struct fbtft_par *par = info->par;
> +
> + if (par->txbuf.len > 0)
Do we really need this check? If txbuf.buf is kept NULL (please, check
this), the kfree() is NULL-aware.
> + kfree(par->txbuf.buf);
> fb_deferred_io_cleanup(info);
> vfree(info->screen_buffer);
> framebuffer_release(info);
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists