On Fri, Oct 30, 2020 at 11:56 AM Andy Shevchenko <[email protected]> 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 <[email protected]> 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
