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.

[1]. https://lore.kernel.org/lkml/20240812223707.32049-1-dakr@kernel.org/

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(-)

-- 
2.34.1

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@kernel.org/
> 
> 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(-)
>

On Mon, Sep 09, 2024 at 07:12:31PM +0200, Vlastimil Babka wrote:
> 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.
 
Sounds good to me. Thanks for the review!

- Feng

> > 
> > [1]. https://lore.kernel.org/lkml/20240812223707.32049-1-dakr@kernel.org/
> > 
> > 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(-)
> > 
>