Messages in this thread | | | Date | Fri, 30 Oct 2020 12:58:34 +0200 | From | Andy Shevchenko <> | Subject | Re: [PATCH] devres: zero the memory in devm_krealloc() if needed |
| |
On Fri, Oct 30, 2020 at 12:57:06PM +0200, Andy Shevchenko wrote: > On Fri, Oct 30, 2020 at 10:03:50AM +0100, Bartosz Golaszewski wrote: > > On Thu, Oct 29, 2020 at 9:05 PM Andy Shevchenko > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > > On Mon, Oct 26, 2020 at 01:27:28PM +0100, Bartosz Golaszewski wrote: > > > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > > > > > > > If we're returning the same pointer (when new size is smaller or equal > > > > to the old size) we need to check if the user wants the memory zeroed > > > > and memset() it manually if so. > > > > > > Any use case? Because to me it sounds contradictory to the whole idea of [k]realloc(). > > > > This is kind of a gray area in original krealloc() too and I want to > > submit a patch for mm too. Right now krealloc ignores the __GFP_ZERO > > flag if new_size <= old_size but zeroes the memory if new_size > > > old_size. > > > This should be consistent - either ignore __GFP_ZERO or > > don't ignore it in both cases. I think that not ignoring it is better > > - if user passes it then it's for a reason. > > Sorry, but I consider in these two choices the best is the former one, i.e. > ignoring, because non-ignoring for sizes less than current is counter the > REalloc() by definition. > > Reading realloc(3): > > "If the new size is larger than the old size, the added memory will not be > initialized." > > So, supports my choice over yours.
Two notes: - perhaps kzrealloc() for what you want - there is a library call reallocarray() which supports your idea about krealloc_array() API in kernel.
-- With Best Regards, Andy Shevchenko
| |