| Message ID | 20220907071023.3838692-4-feng.tang@intel.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mm/slub: some debug enhancements for kmalloc | expand |
On Wed, Sep 7, 2022 at 9:11 AM Feng Tang <feng.tang@intel.com> wrote: > > When kasan is enabled for slab/slub, it may save kasan' free_meta > data in the former part of slab object data area in slab object > free path, which works fine. > > There is ongoing effort to extend slub's debug function which will > redzone the latter part of kmalloc object area, and when both of > the debug are enabled, there is possible conflict, especially when > the kmalloc object has small size, as caught by 0Day bot [1] > > For better information for slab/slub, add free_meta's data size > into 'struct kasan_cache', so that its users can take right action > to avoid data conflict. > > [1]. https://lore.kernel.org/lkml/YuYm3dWwpZwH58Hu@xsang-OptiPlex-9020/ > Reported-by: kernel test robot <oliver.sang@intel.com> > Signed-off-by: Feng Tang <feng.tang@intel.com> > Acked-by: Dmitry Vyukov <dvyukov@google.com> > --- > include/linux/kasan.h | 2 ++ > mm/kasan/common.c | 2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/include/linux/kasan.h b/include/linux/kasan.h > index b092277bf48d..293bdaa0ba09 100644 > --- a/include/linux/kasan.h > +++ b/include/linux/kasan.h > @@ -100,6 +100,8 @@ static inline bool kasan_has_integrated_init(void) > struct kasan_cache { > int alloc_meta_offset; > int free_meta_offset; > + /* size of free_meta data saved in object's data area */ > + int free_meta_size_in_object; I thinks calling this field free_meta_size is clear enough. Thanks! > bool is_kmalloc; > }; > > diff --git a/mm/kasan/common.c b/mm/kasan/common.c > index 69f583855c8b..762ae7a7793e 100644 > --- a/mm/kasan/common.c > +++ b/mm/kasan/common.c > @@ -201,6 +201,8 @@ void __kasan_cache_create(struct kmem_cache *cache, unsigned int *size, > cache->kasan_info.free_meta_offset = KASAN_NO_FREE_META; > *size = ok_size; > } > + } else { > + cache->kasan_info.free_meta_size_in_object = sizeof(struct kasan_free_meta); > } > > /* Calculate size with optimal redzone. */ > -- > 2.34.1 > > -- > You received this message because you are subscribed to the Google Groups "kasan-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20220907071023.3838692-4-feng.tang%40intel.com.
Hi Andrey, Thanks for reviewing this series! On Sun, Sep 11, 2022 at 07:14:55AM +0800, Andrey Konovalov wrote: > On Wed, Sep 7, 2022 at 9:11 AM Feng Tang <feng.tang@intel.com> wrote: > > > > When kasan is enabled for slab/slub, it may save kasan' free_meta > > data in the former part of slab object data area in slab object > > free path, which works fine. > > > > There is ongoing effort to extend slub's debug function which will > > redzone the latter part of kmalloc object area, and when both of > > the debug are enabled, there is possible conflict, especially when > > the kmalloc object has small size, as caught by 0Day bot [1] > > > > For better information for slab/slub, add free_meta's data size > > into 'struct kasan_cache', so that its users can take right action > > to avoid data conflict. > > > > [1]. https://lore.kernel.org/lkml/YuYm3dWwpZwH58Hu@xsang-OptiPlex-9020/ > > Reported-by: kernel test robot <oliver.sang@intel.com> > > Signed-off-by: Feng Tang <feng.tang@intel.com> > > Acked-by: Dmitry Vyukov <dvyukov@google.com> > > --- > > include/linux/kasan.h | 2 ++ > > mm/kasan/common.c | 2 ++ > > 2 files changed, 4 insertions(+) > > > > diff --git a/include/linux/kasan.h b/include/linux/kasan.h > > index b092277bf48d..293bdaa0ba09 100644 > > --- a/include/linux/kasan.h > > +++ b/include/linux/kasan.h > > @@ -100,6 +100,8 @@ static inline bool kasan_has_integrated_init(void) > > struct kasan_cache { > > int alloc_meta_offset; > > int free_meta_offset; > > + /* size of free_meta data saved in object's data area */ > > + int free_meta_size_in_object; > > I thinks calling this field free_meta_size is clear enough. Thanks! Yes, the name does look long. The "in_object" was added to make it also a flag for whether the free meta is saved inside object's data area. For 'free_meta_size', the code logic in slub should be: if (info->free_meta_offset == 0 && info->free_meta_size >= ...) Thanks, Feng
On Sun, Sep 11, 2022 at 5:57 AM Feng Tang <feng.tang@intel.com> wrote: > > Hi Andrey, > > Thanks for reviewing this series! > > On Sun, Sep 11, 2022 at 07:14:55AM +0800, Andrey Konovalov wrote: > > On Wed, Sep 7, 2022 at 9:11 AM Feng Tang <feng.tang@intel.com> wrote: > > > > > > When kasan is enabled for slab/slub, it may save kasan' free_meta > > > data in the former part of slab object data area in slab object > > > free path, which works fine. > > > > > > There is ongoing effort to extend slub's debug function which will > > > redzone the latter part of kmalloc object area, and when both of > > > the debug are enabled, there is possible conflict, especially when > > > the kmalloc object has small size, as caught by 0Day bot [1] > > > > > > For better information for slab/slub, add free_meta's data size > > > into 'struct kasan_cache', so that its users can take right action > > > to avoid data conflict. > > > > > > [1]. https://lore.kernel.org/lkml/YuYm3dWwpZwH58Hu@xsang-OptiPlex-9020/ > > > Reported-by: kernel test robot <oliver.sang@intel.com> > > > Signed-off-by: Feng Tang <feng.tang@intel.com> > > > Acked-by: Dmitry Vyukov <dvyukov@google.com> > > > --- > > > include/linux/kasan.h | 2 ++ > > > mm/kasan/common.c | 2 ++ > > > 2 files changed, 4 insertions(+) > > > > > > diff --git a/include/linux/kasan.h b/include/linux/kasan.h > > > index b092277bf48d..293bdaa0ba09 100644 > > > --- a/include/linux/kasan.h > > > +++ b/include/linux/kasan.h > > > @@ -100,6 +100,8 @@ static inline bool kasan_has_integrated_init(void) > > > struct kasan_cache { > > > int alloc_meta_offset; > > > int free_meta_offset; > > > + /* size of free_meta data saved in object's data area */ > > > + int free_meta_size_in_object; > > > > I thinks calling this field free_meta_size is clear enough. Thanks! > > Yes, the name does look long. The "in_object" was added to make it > also a flag for whether the free meta is saved inside object's data > area. > > For 'free_meta_size', the code logic in slub should be: > > if (info->free_meta_offset == 0 && > info->free_meta_size >= ...) I'd say you can keep the current logic and just rename the field to make it shorter. But up to you, I'm fine with either approach. Thanks!
On Sun, Sep 11, 2022 at 07:51:54PM +0800, Andrey Konovalov wrote: > On Sun, Sep 11, 2022 at 5:57 AM Feng Tang <feng.tang@intel.com> wrote: > > > > Hi Andrey, > > > > Thanks for reviewing this series! > > > > On Sun, Sep 11, 2022 at 07:14:55AM +0800, Andrey Konovalov wrote: > > > On Wed, Sep 7, 2022 at 9:11 AM Feng Tang <feng.tang@intel.com> wrote: > > > > > > > > When kasan is enabled for slab/slub, it may save kasan' free_meta > > > > data in the former part of slab object data area in slab object > > > > free path, which works fine. > > > > > > > > There is ongoing effort to extend slub's debug function which will > > > > redzone the latter part of kmalloc object area, and when both of > > > > the debug are enabled, there is possible conflict, especially when > > > > the kmalloc object has small size, as caught by 0Day bot [1] > > > > > > > > For better information for slab/slub, add free_meta's data size > > > > into 'struct kasan_cache', so that its users can take right action > > > > to avoid data conflict. > > > > > > > > [1]. https://lore.kernel.org/lkml/YuYm3dWwpZwH58Hu@xsang-OptiPlex-9020/ > > > > Reported-by: kernel test robot <oliver.sang@intel.com> > > > > Signed-off-by: Feng Tang <feng.tang@intel.com> > > > > Acked-by: Dmitry Vyukov <dvyukov@google.com> > > > > --- > > > > include/linux/kasan.h | 2 ++ > > > > mm/kasan/common.c | 2 ++ > > > > 2 files changed, 4 insertions(+) > > > > > > > > diff --git a/include/linux/kasan.h b/include/linux/kasan.h > > > > index b092277bf48d..293bdaa0ba09 100644 > > > > --- a/include/linux/kasan.h > > > > +++ b/include/linux/kasan.h > > > > @@ -100,6 +100,8 @@ static inline bool kasan_has_integrated_init(void) > > > > struct kasan_cache { > > > > int alloc_meta_offset; > > > > int free_meta_offset; > > > > + /* size of free_meta data saved in object's data area */ > > > > + int free_meta_size_in_object; > > > > > > I thinks calling this field free_meta_size is clear enough. Thanks! > > > > Yes, the name does look long. The "in_object" was added to make it > > also a flag for whether the free meta is saved inside object's data > > area. > > > > For 'free_meta_size', the code logic in slub should be: > > > > if (info->free_meta_offset == 0 && > > info->free_meta_size >= ...) > > I'd say you can keep the current logic and just rename the field to > make it shorter. But up to you, I'm fine with either approach. Thanks! OK, I don't have strong opinion either. As the comment for that member clearly stats it's for inside-data size info, we could use the shorter name. Thanks, Feng
diff --git a/include/linux/kasan.h b/include/linux/kasan.h index b092277bf48d..293bdaa0ba09 100644 --- a/include/linux/kasan.h +++ b/include/linux/kasan.h @@ -100,6 +100,8 @@ static inline bool kasan_has_integrated_init(void) struct kasan_cache { int alloc_meta_offset; int free_meta_offset; + /* size of free_meta data saved in object's data area */ + int free_meta_size_in_object; bool is_kmalloc; }; diff --git a/mm/kasan/common.c b/mm/kasan/common.c index 69f583855c8b..762ae7a7793e 100644 --- a/mm/kasan/common.c +++ b/mm/kasan/common.c @@ -201,6 +201,8 @@ void __kasan_cache_create(struct kmem_cache *cache, unsigned int *size, cache->kasan_info.free_meta_offset = KASAN_NO_FREE_META; *size = ok_size; } + } else { + cache->kasan_info.free_meta_size_in_object = sizeof(struct kasan_free_meta); } /* Calculate size with optimal redzone. */