On 9/9/24 03:29, Feng Tang wrote: > Danilo Krummrich's patch [1] raised one problem about krealloc() that > its caller doesn't know what's the actual request size, say the object > is 64 bytes kmalloc one, but 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). > > And when some slub debug option is enabled, kmalloc caches do have this > 'orig_size' feature. As suggested by Vlastimil, utilize it to do more > accurate data handling, as well as enforce the kmalloc-redzone sanity check. > > To make the 'orig_size' accurate, we adjust some kasan/slub meta data > handling. Also add a slub kunit test case for krealloc(). > > This patchset has dependency over patches in both -mm tree and -slab > trees, so it is written based on linux-next tree '20240905' version. Thanks, given the timing with merge window opening soon, I would take this into the slab tree after the merge window, when the current -next becomes 6.12-rc1. > > [1]. https://lore.kernel.org/lkml/20240812223707.32049-1-dakr@xxxxxxxxxx/ > > Thanks, > Feng > > Feng Tang (5): > mm/kasan: Don't store metadata inside kmalloc object when > slub_debug_orig_size is on > mm/slub: Consider kfence case for get_orig_size() > mm/slub: Improve redzone check and zeroing for krealloc() > kunit: kfence: Make KFENCE_TEST_REQUIRES macro available for all kunit > case > mm/slub, kunit: Add testcase for krealloc redzone and zeroing > > include/kunit/test.h | 6 ++ > lib/slub_kunit.c | 46 +++++++++++++++ > mm/kasan/generic.c | 5 +- > mm/kfence/kfence_test.c | 9 +-- > mm/slab.h | 6 ++ > mm/slab_common.c | 84 --------------------------- > mm/slub.c | 125 ++++++++++++++++++++++++++++++++++------ > 7 files changed, 171 insertions(+), 110 deletions(-) >
