On Tue, Sep 10, 2024 at 03:15:36PM +0200, Vlastimil Babka wrote: > 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). Right! > > > 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. Will add it. Thanks for the enhancement! > > 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. Yes and will do. Thanks, Feng > Thanks. >
