Messages in this thread | | | From | Bartosz Golaszewski <> | Date | Fri, 30 Oct 2020 12:03:35 +0100 | Subject | Re: [PATCH] devres: zero the memory in devm_krealloc() if needed |
| |
On Fri, Oct 30, 2020 at 11:56 AM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: >
[snip]
> > > > > > 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.
Kernel memory management API is not really orthogonal to the one in user-space. For example: kmalloc() takes the gfp parameter and if you pass __GFP_ZERO to it, it zeroes the memory even if user-space malloc() never does.
On Fri, Oct 30, 2020 at 11:57 AM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: >
[snip]
> > Two notes: > - perhaps kzrealloc() for what you want
It could be used as a helper wrapper around krealloc() but kzalloc() is already a simple kmalloc() with additional __GFP_ZERO flag passed. This is why I think krealloc() should honor __GFP_ZERO.
> - there is a library call reallocarray() which supports your idea about > krealloc_array() API in kernel. >
reallocarray() is a bsd extension. I'd stick to krealloc_array() naming in the kernel.
Bartosz
| |