On Fri, Oct 30, 2020 at 12:03 PM Bartosz Golaszewski <[email protected]> wrote: > > 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. >
Ok so I was wrong - it turns out that krealloc() is consistent in ignoring __GFP_ZERO after all. In that case this patch can be dropped. Bartosz
