On 9/9/24 03:29, Feng Tang wrote: > For current krealloc(), one problem is its caller doesn't know what's > the actual request size, say the object is 64 bytes kmalloc one, but It's more accurate to say the caller doesn't pass the old size (it might actually know it). > the original caller may only requested 48 bytes. And when krealloc() > shrinks or grows in the same object, or allocate a new bigger object, > it lacks this 'original size' information to do accurate data preserving > or zeroing (when __GFP_ZERO is set). Let's describe the problem specifically by adding: Thus with slub debug redzone and object tracking enabled, parts of the object after krealloc() might contain redzone data instead of zeroes, which is violating the __GFP_ZERO guarantees. > And when some slub debug option is enabled, kmalloc caches do have this > 'orig_size' feature. So utilize it to do more accurate data handling, > as well as enforce the kmalloc-redzone sanity check. > > The krealloc() related code is moved from slab_common.c to slub.c for > more efficient function calling. Agreed with Danilo that having the move as separate preparatory patch would make review easier. Thanks.
