[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZQl8tkWnQcjtFBbQ@smile.fi.intel.com>
Date: Tue, 19 Sep 2023 13:49:26 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: brgl@...ev.pl
Cc: Linus Walleij <linus.walleij@...aro.org>,
Kent Gibson <warthog618@...il.com>,
Alexey Dobriyan <adobriyan@...il.com>,
Peter Zijlstra <peterz@...radead.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
akpm@...ux-foundation.org, linux-gpio@...r.kernel.org,
linux-kernel@...r.kernel.org,
Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH v4] gpio: sim: fix an invalid __free() usage
On Tue, Sep 19, 2023 at 12:31:36AM -0700, brgl@...ev.pl wrote:
> On Mon, 18 Sep 2023 17:31:36 +0200, Andy Shevchenko
> <andriy.shevchenko@...ux.intel.com> said:
> > On Mon, Sep 18, 2023 at 04:55:33PM +0200, Bartosz Golaszewski wrote:
...
> > Of course this can be replace with...
> >
> >> + line_names = kcalloc(line_names_size, sizeof(*line_names),
> >> + GFP_KERNEL);
> >
> >> + if (!line_names)
> >
> > ZERO_OR_NULL_PTR() check here, but I assume we discourage use of it.
>
> Why? There are less than 40 instances of using it in the kernel. kmalloc()
> returns NULL on failure.
Nope, k*alloc*() returns ZERO or NULL on failure. That's what most developers
are missing :-)
> >> + return ERR_PTR(-ENOMEM);
Hence either one needs to check for 0 the size given to the kmalloc(),
_or_ to check for all possible return values from it.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists