From: Feng Tang <feng.tang@intel.com>
To: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
Hyeonggon Yoo <42.hyeyoo@gmail.com>,
Dmitry Vyukov <dvyukov@google.com>,
Jonathan Corbet <corbet@lwn.net>,
"Hansen, Dave" <dave.hansen@intel.com>,
Linux Memory Management List <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
kasan-dev <kasan-dev@googlegroups.com>,
"Sang, Oliver" <oliver.sang@intel.com>
Subject: Re: [PATCH v6 3/4] mm: kasan: Add free_meta size info in struct kasan_cache
Date: Wed, 21 Sep 2022 20:02:45 +0800 [thread overview]
Message-ID: <Yyr9ZZnVPgr4GHYQ@feng-clx> (raw)
In-Reply-To: <CA+fCnZdFi471MxQG9RduQcBZWR10GCqxyNkuaDXzX6y4zCaYAQ@mail.gmail.com>
Hi Andrey,
On Wed, Sep 21, 2022 at 03:20:58AM +0800, Andrey Konovalov wrote:
> On Tue, Sep 13, 2022 at 8:54 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's
> > 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..49af9513e8ed 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;
> > bool is_kmalloc;
> > };
> >
> > diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> > index 69f583855c8b..0cb867e92524 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 = sizeof(struct kasan_free_meta);
>
> Hi Feng,
>
> I just realized that we already have a function that exposes a similar
> functionality: kasan_metadata_size. However, this function returns the
> size of metadata that is stored in the redzone.
>
> I think, instead of adding free_meta_size, a better approach would be to:
>
> 1. Rename kasan_metadata_size to kasan_metadata_size_in_redzone (or
> something like that).
> 2. Add kasan_metadata_size_in_object with appropriate implementation
> and use that in your patches.
>
> This allows avoiding exposing KASAN-internal details such as what kind
> of fields the kasan_cache struct has to the common code.
Agree, it's better not touch the internal fields in slub code.
How about the following patch, it merge the 2 functions with one flag
indicating in meta data or object. (I'm fine with 2 separate functions)
diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index b092277bf48d..0ad05a34e708 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -150,11 +150,12 @@ static __always_inline void kasan_cache_create_kmalloc(struct kmem_cache *cache)
__kasan_cache_create_kmalloc(cache);
}
-size_t __kasan_metadata_size(struct kmem_cache *cache);
-static __always_inline size_t kasan_metadata_size(struct kmem_cache *cache)
+size_t __kasan_meta_size(struct kmem_cache *cache, bool in_slab_object);
+static __always_inline size_t kasan_meta_size(struct kmem_cache *cache,
+ bool in_slab_object)
{
if (kasan_enabled())
- return __kasan_metadata_size(cache);
+ return __kasan_meta_size(cache, in_slab_object);
return 0;
}
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index 69f583855c8b..2a8710461ebb 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -218,14 +218,21 @@ void __kasan_cache_create_kmalloc(struct kmem_cache *cache)
cache->kasan_info.is_kmalloc = true;
}
-size_t __kasan_metadata_size(struct kmem_cache *cache)
+size_t __kasan_meta_size(struct kmem_cache *cache, bool in_slab_object)
{
if (!kasan_stack_collection_enabled())
return 0;
- return (cache->kasan_info.alloc_meta_offset ?
- sizeof(struct kasan_alloc_meta) : 0) +
- (cache->kasan_info.free_meta_offset ?
- sizeof(struct kasan_free_meta) : 0);
+
+ if (in_slab_object)
+ return (cache->kasan_info.alloc_meta_offset == 0 ?
+ sizeof(struct kasan_alloc_meta) : 0) +
+ (cache->kasan_info.free_meta_offset ?
+ sizeof(struct kasan_free_meta) : 0);
+ else
+ return (cache->kasan_info.alloc_meta_offset == 0 ?
+ sizeof(struct kasan_alloc_meta) : 0) +
+ (cache->kasan_info.free_meta_offset ?
+ sizeof(struct kasan_free_meta) : 0);
}
struct kasan_alloc_meta *kasan_get_alloc_meta(struct kmem_cache *cache,
> Sorry for nor realizing this straight away.
>
> (Note that there's an upcoming patch that fixes a bug in
> kasan_metadata_size' implementation [1].)
Thanks for the note, will check this when making the formal patch.
- Feng
> Thanks!
>
> [1] https://lore.kernel.org/linux-mm/c7b316d30d90e5947eb8280f4dc78856a49298cf.1662411799.git.andreyknvl@google.com/
next prev parent reply other threads:[~2022-09-21 12:03 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-13 6:54 [PATCH v6 0/4] mm/slub: some debug enhancements for kmalloc Feng Tang
2022-09-13 6:54 ` [PATCH v6 1/4] mm/slub: enable debugging memory wasting of kmalloc Feng Tang
2022-09-23 11:43 ` Vlastimil Babka
2022-09-24 7:08 ` Feng Tang
2022-10-30 19:23 ` John Thomson
2022-10-30 21:30 ` Vlastimil Babka
2022-10-31 2:36 ` Feng Tang
2022-10-31 10:05 ` John Thomson
2022-10-31 11:36 ` Hyeonggon Yoo
2022-10-31 11:42 ` Feng Tang
2022-11-01 0:18 ` John Thomson
2022-11-01 2:41 ` John Thomson
2022-11-01 7:57 ` Feng Tang
2022-11-01 9:20 ` John Thomson
2022-11-01 9:31 ` Hyeonggon Yoo
2022-11-01 10:33 ` John Thomson
2022-11-01 10:42 ` Hyeonggon Yoo
2022-11-01 13:55 ` Feng Tang
2022-11-01 19:39 ` John Thomson
2022-11-02 6:08 ` Feng Tang
2022-11-02 7:16 ` Hyeonggon Yoo
2022-11-03 7:18 ` Feng Tang
2022-11-03 7:45 ` John Thomson
2022-11-03 8:16 ` Feng Tang
2022-11-02 8:22 ` Vlastimil Babka
2022-11-03 5:54 ` Feng Tang
2022-11-03 8:33 ` Vlastimil Babka
2022-11-03 14:16 ` Feng Tang
2022-11-03 14:36 ` Hyeonggon Yoo
2022-11-03 16:57 ` Vlastimil Babka
2022-11-03 17:35 ` Vlastimil Babka
2022-11-04 3:52 ` Feng Tang
2022-09-13 6:54 ` [PATCH v6 2/4] mm/slub: only zero the requested size of buffer for kzalloc Feng Tang
2022-09-26 19:11 ` Andrey Konovalov
2022-09-26 20:15 ` Kees Cook
2022-09-27 1:22 ` Feng Tang
2022-09-27 2:42 ` Feng Tang
2022-10-13 14:00 ` Andrey Konovalov
2022-10-14 5:59 ` Feng Tang
2022-09-13 6:54 ` [PATCH v6 3/4] mm: kasan: Add free_meta size info in struct kasan_cache Feng Tang
2022-09-20 19:20 ` Andrey Konovalov
2022-09-21 12:02 ` Feng Tang [this message]
2022-09-24 18:05 ` Andrey Konovalov
2022-09-25 11:26 ` Feng Tang
2022-09-25 16:31 ` Andrey Konovalov
2022-09-27 3:03 ` Feng Tang
2022-09-13 6:54 ` [PATCH v6 4/4] mm/slub: extend redzone check to extra allocated kmalloc space than requested Feng Tang
2022-09-13 8:53 ` Hyeonggon Yoo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yyr9ZZnVPgr4GHYQ@feng-clx \
--to=feng.tang@intel.com \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=cl@linux.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@intel.com \
--cc=dvyukov@google.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=oliver.sang@intel.com \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.