All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hyeonggon Yoo <42.hyeyoo@gmail.com>
To: Marco Elver <elver@google.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
	kernel test robot <oliver.sang@intel.com>,
	Oliver Glitta <glittao@gmail.com>,
	lkp@lists.01.org, lkp@intel.com,
	LKML <linux-kernel@vger.kernel.org>,
	Imran Khan <imran.f.khan@oracle.com>,
	Andrey Konovalov <andreyknvl@google.com>,
	Zhen Lei <thunder.leizhen@huawei.com>,
	Zqiang <qiang.zhang@windriver.com>,
	linux-mm@kvack.org
Subject: Re: [mm/slub] 555b8c8cb3: WARNING:at_lib/stackdepot.c:#stack_depot_fetch
Date: Wed, 6 Apr 2022 07:47:55 +0900	[thread overview]
Message-ID: <YkzHG64zxu+nWbg3@hyeyoo> (raw)
In-Reply-To: <YkwjCUbTbRqslphe@elver.google.com>

On Tue, Apr 05, 2022 at 01:07:53PM +0200, Marco Elver wrote:
> On Tue, Apr 05, 2022 at 11:00AM +0900, Hyeonggon Yoo wrote:
> > On Mon, Apr 04, 2022 at 05:18:16PM +0200, Marco Elver wrote:
> > > On Mon, 4 Apr 2022 at 16:20, Vlastimil Babka <vbabka@suse.cz> wrote:
> [...]
> > > > But here we are in mem_dump_obj() -> kmem_dump_obj() -> kmem_obj_info().
> > > > Because kmem_valid_obj() returned true, fooled by folio_test_slab()
> > > > returning true because of the /* Set required slab fields. */ code.
> > > > Yet the illusion is not perfect and we read garbage instead of a valid
> > > > stackdepot handle.
> > > >
> > > > IMHO we should e.g. add the appropriate is_kfence_address() test into
> > > > kmem_valid_obj(), to exclude kfence-allocated objects? Sounds much simpler
> > > > than trying to extend the illusion further to make kmem_dump_obj() work?
> > > > Instead kfence could add its own specific handler to mem_dump_obj() to print
> > > > its debugging data?
> > > 
> > > I think this explanation makes sense!  Indeed, KFENCE already records
> > > allocation stacks internally anyway, so it should be straightforward
> > > to convince it to just print that.
> > >
> > 
> > Thank you both! Yeah the explanation makes sense... thats why KASAN/KCSAN couldn't yield anything -- it was not overwritten.
> > 
> > I'm writing a fix and will test if the bug disappears.
> > This may take few days.
>

I did check the bug is not reproduced after simple fix. (reproduced 0 of 373)
This approach was right.

> The below should fix it -- I'd like to make kmem_obj_info() do something
> useful for KFENCE objects.
>

Agreed.

> I lightly tested it by calling mem_dump_obj() on a KFENCE object, and
> prior to the below patch it'd produce garbage data.
> 
> Does that look reasonable to you?
> 
> Thanks,
> -- Marco
> 
> ------ >8 ------
> 
> From 09f32964284110846ded8ade9a1a2bfcb17dc58e Mon Sep 17 00:00:00 2001
> From: Marco Elver <elver@google.com>
> Date: Tue, 5 Apr 2022 12:43:48 +0200
> Subject: [PATCH RFC] kfence, slab, slub: support kmem_obj_info() with KFENCE
>  objects
> 
> Calling kmem_obj_info() on KFENCE objects has been producing garbage
> data due to the object not actually being maintained by SLAB or SLUB.
> 
> Fix this by asking KFENCE to copy missing KFENCE-specific information to
> struct kmem_obj_info when the object was allocated by KFENCE.
> 
> Link: https://lore.kernel.org/all/20220323090520.GG16885@xsang-OptiPlex-9020/
> Fixes: b89fb5ef0ce6 ("mm, kfence: insert KFENCE hooks for SLUB")
> Fixes: d3fb45f370d9 ("mm, kfence: insert KFENCE hooks for SLAB")
> Reported-by: kernel test robot <oliver.sang@intel.com>
> Signed-off-by: Marco Elver <elver@google.com>
> ---
>  include/linux/kfence.h | 22 ++++++++++++++++++++++
>  mm/kfence/core.c       | 21 ---------------------
>  mm/kfence/kfence.h     | 21 +++++++++++++++++++++
>  mm/kfence/report.c     | 34 ++++++++++++++++++++++++++++++++++
>  mm/slab.c              |  4 ++++
>  mm/slub.c              |  4 ++++
>  6 files changed, 85 insertions(+), 21 deletions(-)
> 
> diff --git a/include/linux/kfence.h b/include/linux/kfence.h
> index f49e64222628..4a7c633cb219 100644
> --- a/include/linux/kfence.h
> +++ b/include/linux/kfence.h
> @@ -204,6 +204,23 @@ static __always_inline __must_check bool kfence_free(void *addr)
>   */
>  bool __must_check kfence_handle_page_fault(unsigned long addr, bool is_write, struct pt_regs *regs);
>  
> +#ifdef CONFIG_PRINTK
> +struct kmem_obj_info;
> +/**
> + * kfence_kmem_obj_info() - fill kmem_obj_info struct
> + * @kpp: kmem_obj_info to be filled
> + * @object: the object
> + *
> + * Return:
> + * * false - not a KFENCE object
> + * * true - a KFENCE object and filled @kpp
> + *
> + * Copies information to @kpp that kmem_obj_info() is unable to populate for
> + * KFENCE objects.
> + */
> +bool kfence_kmem_obj_info(struct kmem_obj_info *kpp, void *object);
> +#endif
> +
>  #else /* CONFIG_KFENCE */
>  
>  static inline bool is_kfence_address(const void *addr) { return false; }
> @@ -221,6 +238,11 @@ static inline bool __must_check kfence_handle_page_fault(unsigned long addr, boo
>  	return false;
>  }
>  
> +#ifdef CONFIG_PRINTK
> +struct kmem_obj_info;
> +static inline bool kfence_kmem_obj_info(struct kmem_obj_info *kpp, void *object) { return false; }
> +#endif
> +
>  #endif
>  
>  #endif /* _LINUX_KFENCE_H */
> diff --git a/mm/kfence/core.c b/mm/kfence/core.c
> index a203747ad2c0..9b2b5f56f4ae 100644
> --- a/mm/kfence/core.c
> +++ b/mm/kfence/core.c
> @@ -231,27 +231,6 @@ static bool kfence_unprotect(unsigned long addr)
>  	return !KFENCE_WARN_ON(!kfence_protect_page(ALIGN_DOWN(addr, PAGE_SIZE), false));
>  }
>  
> -static inline struct kfence_metadata *addr_to_metadata(unsigned long addr)
> -{
> -	long index;
> -
> -	/* The checks do not affect performance; only called from slow-paths. */
> -
> -	if (!is_kfence_address((void *)addr))
> -		return NULL;
> -
> -	/*
> -	 * May be an invalid index if called with an address at the edge of
> -	 * __kfence_pool, in which case we would report an "invalid access"
> -	 * error.
> -	 */
> -	index = (addr - (unsigned long)__kfence_pool) / (PAGE_SIZE * 2) - 1;
> -	if (index < 0 || index >= CONFIG_KFENCE_NUM_OBJECTS)
> -		return NULL;
> -
> -	return &kfence_metadata[index];
> -}
> -
>  static inline unsigned long metadata_to_pageaddr(const struct kfence_metadata *meta)
>  {
>  	unsigned long offset = (meta - kfence_metadata + 1) * PAGE_SIZE * 2;
> diff --git a/mm/kfence/kfence.h b/mm/kfence/kfence.h
> index 9a6c4b1b12a8..600f2e2431d6 100644
> --- a/mm/kfence/kfence.h
> +++ b/mm/kfence/kfence.h
> @@ -96,6 +96,27 @@ struct kfence_metadata {
>  
>  extern struct kfence_metadata kfence_metadata[CONFIG_KFENCE_NUM_OBJECTS];
>  
> +static inline struct kfence_metadata *addr_to_metadata(unsigned long addr)
> +{
> +	long index;
> +
> +	/* The checks do not affect performance; only called from slow-paths. */
> +
> +	if (!is_kfence_address((void *)addr))
> +		return NULL;
> +
> +	/*
> +	 * May be an invalid index if called with an address at the edge of
> +	 * __kfence_pool, in which case we would report an "invalid access"
> +	 * error.
> +	 */
> +	index = (addr - (unsigned long)__kfence_pool) / (PAGE_SIZE * 2) - 1;
> +	if (index < 0 || index >= CONFIG_KFENCE_NUM_OBJECTS)
> +		return NULL;
> +
> +	return &kfence_metadata[index];
> +}
> +
>  /* KFENCE error types for report generation. */
>  enum kfence_error_type {
>  	KFENCE_ERROR_OOB,		/* Detected a out-of-bounds access. */
> diff --git a/mm/kfence/report.c b/mm/kfence/report.c
> index f93a7b2a338b..5887fa610c9d 100644
> --- a/mm/kfence/report.c
> +++ b/mm/kfence/report.c
> @@ -273,3 +273,37 @@ void kfence_report_error(unsigned long address, bool is_write, struct pt_regs *r
>  	/* We encountered a memory safety error, taint the kernel! */
>  	add_taint(TAINT_BAD_PAGE, LOCKDEP_STILL_OK);
>  }
> +
> +#ifdef CONFIG_PRINTK
> +static void kfence_to_kp_stack(const struct kfence_track *track, void **kp_stack)
> +{
> +	int i, j;
> +
> +	i = get_stack_skipnr(track->stack_entries, track->num_stack_entries, NULL);
> +	for (j = 0; i < track->num_stack_entries && j < KS_ADDRS_COUNT - 1; ++i, ++j)

why KS_ADDRS_COUNT - 1 instead of KS_ADDRS_COUNT?

> +		kp_stack[j] = (void *)track->stack_entries[i];
> +	kp_stack[j] = NULL;
> +}
> +
> +bool kfence_kmem_obj_info(struct kmem_obj_info *kpp, void *object)
> +{
> +	const struct kfence_metadata *meta = addr_to_metadata((unsigned long)object);
> +
> +	if (!meta)
> +		return false;
> +
> +	/* Requesting info an a never-used object is almost certainly a bug. */
> +	if (WARN_ON(meta->state == KFENCE_OBJECT_UNUSED))
> +		return true;
> +
> +	kpp->kp_objp = (void *)meta->addr;
> +

no need to take meta->lock here?

> +	kfence_to_kp_stack(&meta->alloc_track, kpp->kp_stack);
> +	if (meta->state == KFENCE_OBJECT_FREED)
> +		kfence_to_kp_stack(&meta->free_track, kpp->kp_free_stack);
> +	/* get_stack_skipnr() ensures the first entry is outside allocator. */
> +	kpp->kp_ret = kpp->kp_stack[0];
> +
> +	return true;
> +}

kfence_kmem_obj_info() does not set kp_data_offset. kp_data_offset
may not be zero when e.g.) mem_dump_obj(&rhp->func); in rcutorture case. 

BTW, I would prefer implementing something like kfence_obj_info()
(called by kmem_dump_obj() and called instead of kmem_obj_info())
for better readability.

And when mem_dump_obj() is called, I guess it's for debugging purpose.
I think it would be better to let user know the object is allocated
from kfence pool. maybe adding if (is_kfence_address(object)) pr_cont(" kfence");
in kmem_dump_obj() would be enough?

Thanks!
Hyeonggon

> +#endif
> diff --git a/mm/slab.c b/mm/slab.c
> index b04e40078bdf..4d44b094e0ab 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -3675,6 +3675,10 @@ void kmem_obj_info(struct kmem_obj_info *kpp, void *object, struct slab *slab)
>  	kpp->kp_slab = slab;
>  	cachep = slab->slab_cache;
>  	kpp->kp_slab_cache = cachep;
> +
> +	if (kfence_kmem_obj_info(kpp, object))
> +		return;
> +
>  	objp = object - obj_offset(cachep);
>  	kpp->kp_data_offset = obj_offset(cachep);
>  	slab = virt_to_slab(objp);
> diff --git a/mm/slub.c b/mm/slub.c
> index 74d92aa4a3a2..c7d2cfd60b87 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -4325,6 +4325,10 @@ void kmem_obj_info(struct kmem_obj_info *kpp, void *object, struct slab *slab)
>  	kpp->kp_ptr = object;
>  	kpp->kp_slab = slab;
>  	kpp->kp_slab_cache = s;
> +
> +	if (kfence_kmem_obj_info(kpp, object))
> +		return;
> +
>  	base = slab_address(slab);
>  	objp0 = kasan_reset_tag(object);
>  #ifdef CONFIG_SLUB_DEBUG
> -- 
> 2.35.1.1094.g7c7d902a7c-goog
> 

WARNING: multiple messages have this Message-ID (diff)
From: Hyeonggon Yoo <42.hyeyoo@gmail.com>
To: lkp@lists.01.org
Subject: Re: [mm/slub] 555b8c8cb3: WARNING:at_lib/stackdepot.c:#stack_depot_fetch
Date: Wed, 06 Apr 2022 07:47:55 +0900	[thread overview]
Message-ID: <YkzHG64zxu+nWbg3@hyeyoo> (raw)
In-Reply-To: <YkwjCUbTbRqslphe@elver.google.com>

[-- Attachment #1: Type: text/plain, Size: 9881 bytes --]

On Tue, Apr 05, 2022 at 01:07:53PM +0200, Marco Elver wrote:
> On Tue, Apr 05, 2022 at 11:00AM +0900, Hyeonggon Yoo wrote:
> > On Mon, Apr 04, 2022 at 05:18:16PM +0200, Marco Elver wrote:
> > > On Mon, 4 Apr 2022 at 16:20, Vlastimil Babka <vbabka@suse.cz> wrote:
> [...]
> > > > But here we are in mem_dump_obj() -> kmem_dump_obj() -> kmem_obj_info().
> > > > Because kmem_valid_obj() returned true, fooled by folio_test_slab()
> > > > returning true because of the /* Set required slab fields. */ code.
> > > > Yet the illusion is not perfect and we read garbage instead of a valid
> > > > stackdepot handle.
> > > >
> > > > IMHO we should e.g. add the appropriate is_kfence_address() test into
> > > > kmem_valid_obj(), to exclude kfence-allocated objects? Sounds much simpler
> > > > than trying to extend the illusion further to make kmem_dump_obj() work?
> > > > Instead kfence could add its own specific handler to mem_dump_obj() to print
> > > > its debugging data?
> > > 
> > > I think this explanation makes sense!  Indeed, KFENCE already records
> > > allocation stacks internally anyway, so it should be straightforward
> > > to convince it to just print that.
> > >
> > 
> > Thank you both! Yeah the explanation makes sense... thats why KASAN/KCSAN couldn't yield anything -- it was not overwritten.
> > 
> > I'm writing a fix and will test if the bug disappears.
> > This may take few days.
>

I did check the bug is not reproduced after simple fix. (reproduced 0 of 373)
This approach was right.

> The below should fix it -- I'd like to make kmem_obj_info() do something
> useful for KFENCE objects.
>

Agreed.

> I lightly tested it by calling mem_dump_obj() on a KFENCE object, and
> prior to the below patch it'd produce garbage data.
> 
> Does that look reasonable to you?
> 
> Thanks,
> -- Marco
> 
> ------ >8 ------
> 
> From 09f32964284110846ded8ade9a1a2bfcb17dc58e Mon Sep 17 00:00:00 2001
> From: Marco Elver <elver@google.com>
> Date: Tue, 5 Apr 2022 12:43:48 +0200
> Subject: [PATCH RFC] kfence, slab, slub: support kmem_obj_info() with KFENCE
>  objects
> 
> Calling kmem_obj_info() on KFENCE objects has been producing garbage
> data due to the object not actually being maintained by SLAB or SLUB.
> 
> Fix this by asking KFENCE to copy missing KFENCE-specific information to
> struct kmem_obj_info when the object was allocated by KFENCE.
> 
> Link: https://lore.kernel.org/all/20220323090520.GG16885(a)xsang-OptiPlex-9020/
> Fixes: b89fb5ef0ce6 ("mm, kfence: insert KFENCE hooks for SLUB")
> Fixes: d3fb45f370d9 ("mm, kfence: insert KFENCE hooks for SLAB")
> Reported-by: kernel test robot <oliver.sang@intel.com>
> Signed-off-by: Marco Elver <elver@google.com>
> ---
>  include/linux/kfence.h | 22 ++++++++++++++++++++++
>  mm/kfence/core.c       | 21 ---------------------
>  mm/kfence/kfence.h     | 21 +++++++++++++++++++++
>  mm/kfence/report.c     | 34 ++++++++++++++++++++++++++++++++++
>  mm/slab.c              |  4 ++++
>  mm/slub.c              |  4 ++++
>  6 files changed, 85 insertions(+), 21 deletions(-)
> 
> diff --git a/include/linux/kfence.h b/include/linux/kfence.h
> index f49e64222628..4a7c633cb219 100644
> --- a/include/linux/kfence.h
> +++ b/include/linux/kfence.h
> @@ -204,6 +204,23 @@ static __always_inline __must_check bool kfence_free(void *addr)
>   */
>  bool __must_check kfence_handle_page_fault(unsigned long addr, bool is_write, struct pt_regs *regs);
>  
> +#ifdef CONFIG_PRINTK
> +struct kmem_obj_info;
> +/**
> + * kfence_kmem_obj_info() - fill kmem_obj_info struct
> + * @kpp: kmem_obj_info to be filled
> + * @object: the object
> + *
> + * Return:
> + * * false - not a KFENCE object
> + * * true - a KFENCE object and filled @kpp
> + *
> + * Copies information to @kpp that kmem_obj_info() is unable to populate for
> + * KFENCE objects.
> + */
> +bool kfence_kmem_obj_info(struct kmem_obj_info *kpp, void *object);
> +#endif
> +
>  #else /* CONFIG_KFENCE */
>  
>  static inline bool is_kfence_address(const void *addr) { return false; }
> @@ -221,6 +238,11 @@ static inline bool __must_check kfence_handle_page_fault(unsigned long addr, boo
>  	return false;
>  }
>  
> +#ifdef CONFIG_PRINTK
> +struct kmem_obj_info;
> +static inline bool kfence_kmem_obj_info(struct kmem_obj_info *kpp, void *object) { return false; }
> +#endif
> +
>  #endif
>  
>  #endif /* _LINUX_KFENCE_H */
> diff --git a/mm/kfence/core.c b/mm/kfence/core.c
> index a203747ad2c0..9b2b5f56f4ae 100644
> --- a/mm/kfence/core.c
> +++ b/mm/kfence/core.c
> @@ -231,27 +231,6 @@ static bool kfence_unprotect(unsigned long addr)
>  	return !KFENCE_WARN_ON(!kfence_protect_page(ALIGN_DOWN(addr, PAGE_SIZE), false));
>  }
>  
> -static inline struct kfence_metadata *addr_to_metadata(unsigned long addr)
> -{
> -	long index;
> -
> -	/* The checks do not affect performance; only called from slow-paths. */
> -
> -	if (!is_kfence_address((void *)addr))
> -		return NULL;
> -
> -	/*
> -	 * May be an invalid index if called with an address at the edge of
> -	 * __kfence_pool, in which case we would report an "invalid access"
> -	 * error.
> -	 */
> -	index = (addr - (unsigned long)__kfence_pool) / (PAGE_SIZE * 2) - 1;
> -	if (index < 0 || index >= CONFIG_KFENCE_NUM_OBJECTS)
> -		return NULL;
> -
> -	return &kfence_metadata[index];
> -}
> -
>  static inline unsigned long metadata_to_pageaddr(const struct kfence_metadata *meta)
>  {
>  	unsigned long offset = (meta - kfence_metadata + 1) * PAGE_SIZE * 2;
> diff --git a/mm/kfence/kfence.h b/mm/kfence/kfence.h
> index 9a6c4b1b12a8..600f2e2431d6 100644
> --- a/mm/kfence/kfence.h
> +++ b/mm/kfence/kfence.h
> @@ -96,6 +96,27 @@ struct kfence_metadata {
>  
>  extern struct kfence_metadata kfence_metadata[CONFIG_KFENCE_NUM_OBJECTS];
>  
> +static inline struct kfence_metadata *addr_to_metadata(unsigned long addr)
> +{
> +	long index;
> +
> +	/* The checks do not affect performance; only called from slow-paths. */
> +
> +	if (!is_kfence_address((void *)addr))
> +		return NULL;
> +
> +	/*
> +	 * May be an invalid index if called with an address at the edge of
> +	 * __kfence_pool, in which case we would report an "invalid access"
> +	 * error.
> +	 */
> +	index = (addr - (unsigned long)__kfence_pool) / (PAGE_SIZE * 2) - 1;
> +	if (index < 0 || index >= CONFIG_KFENCE_NUM_OBJECTS)
> +		return NULL;
> +
> +	return &kfence_metadata[index];
> +}
> +
>  /* KFENCE error types for report generation. */
>  enum kfence_error_type {
>  	KFENCE_ERROR_OOB,		/* Detected a out-of-bounds access. */
> diff --git a/mm/kfence/report.c b/mm/kfence/report.c
> index f93a7b2a338b..5887fa610c9d 100644
> --- a/mm/kfence/report.c
> +++ b/mm/kfence/report.c
> @@ -273,3 +273,37 @@ void kfence_report_error(unsigned long address, bool is_write, struct pt_regs *r
>  	/* We encountered a memory safety error, taint the kernel! */
>  	add_taint(TAINT_BAD_PAGE, LOCKDEP_STILL_OK);
>  }
> +
> +#ifdef CONFIG_PRINTK
> +static void kfence_to_kp_stack(const struct kfence_track *track, void **kp_stack)
> +{
> +	int i, j;
> +
> +	i = get_stack_skipnr(track->stack_entries, track->num_stack_entries, NULL);
> +	for (j = 0; i < track->num_stack_entries && j < KS_ADDRS_COUNT - 1; ++i, ++j)

why KS_ADDRS_COUNT - 1 instead of KS_ADDRS_COUNT?

> +		kp_stack[j] = (void *)track->stack_entries[i];
> +	kp_stack[j] = NULL;
> +}
> +
> +bool kfence_kmem_obj_info(struct kmem_obj_info *kpp, void *object)
> +{
> +	const struct kfence_metadata *meta = addr_to_metadata((unsigned long)object);
> +
> +	if (!meta)
> +		return false;
> +
> +	/* Requesting info an a never-used object is almost certainly a bug. */
> +	if (WARN_ON(meta->state == KFENCE_OBJECT_UNUSED))
> +		return true;
> +
> +	kpp->kp_objp = (void *)meta->addr;
> +

no need to take meta->lock here?

> +	kfence_to_kp_stack(&meta->alloc_track, kpp->kp_stack);
> +	if (meta->state == KFENCE_OBJECT_FREED)
> +		kfence_to_kp_stack(&meta->free_track, kpp->kp_free_stack);
> +	/* get_stack_skipnr() ensures the first entry is outside allocator. */
> +	kpp->kp_ret = kpp->kp_stack[0];
> +
> +	return true;
> +}

kfence_kmem_obj_info() does not set kp_data_offset. kp_data_offset
may not be zero when e.g.) mem_dump_obj(&rhp->func); in rcutorture case. 

BTW, I would prefer implementing something like kfence_obj_info()
(called by kmem_dump_obj() and called instead of kmem_obj_info())
for better readability.

And when mem_dump_obj() is called, I guess it's for debugging purpose.
I think it would be better to let user know the object is allocated
from kfence pool. maybe adding if (is_kfence_address(object)) pr_cont(" kfence");
in kmem_dump_obj() would be enough?

Thanks!
Hyeonggon

> +#endif
> diff --git a/mm/slab.c b/mm/slab.c
> index b04e40078bdf..4d44b094e0ab 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -3675,6 +3675,10 @@ void kmem_obj_info(struct kmem_obj_info *kpp, void *object, struct slab *slab)
>  	kpp->kp_slab = slab;
>  	cachep = slab->slab_cache;
>  	kpp->kp_slab_cache = cachep;
> +
> +	if (kfence_kmem_obj_info(kpp, object))
> +		return;
> +
>  	objp = object - obj_offset(cachep);
>  	kpp->kp_data_offset = obj_offset(cachep);
>  	slab = virt_to_slab(objp);
> diff --git a/mm/slub.c b/mm/slub.c
> index 74d92aa4a3a2..c7d2cfd60b87 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -4325,6 +4325,10 @@ void kmem_obj_info(struct kmem_obj_info *kpp, void *object, struct slab *slab)
>  	kpp->kp_ptr = object;
>  	kpp->kp_slab = slab;
>  	kpp->kp_slab_cache = s;
> +
> +	if (kfence_kmem_obj_info(kpp, object))
> +		return;
> +
>  	base = slab_address(slab);
>  	objp0 = kasan_reset_tag(object);
>  #ifdef CONFIG_SLUB_DEBUG
> -- 
> 2.35.1.1094.g7c7d902a7c-goog
> 

  reply	other threads:[~2022-04-06  2:53 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-23  9:05 [mm/slub] 555b8c8cb3: WARNING:at_lib/stackdepot.c:#stack_depot_fetch kernel test robot
2022-03-23  9:05 ` kernel test robot
2022-03-24  9:52 ` Hyeonggon Yoo
2022-03-24  9:52   ` Hyeonggon Yoo
2022-04-01 15:50   ` Hyeonggon Yoo
2022-04-01 15:50     ` Hyeonggon Yoo
2022-04-04  3:05     ` Hyeonggon Yoo
2022-04-04  3:05       ` Hyeonggon Yoo
2022-04-04  8:10       ` Marco Elver
2022-04-04  8:10         ` Marco Elver
2022-04-04 14:20         ` Vlastimil Babka
2022-04-04 14:20           ` Vlastimil Babka
2022-04-04 15:18           ` Marco Elver
2022-04-04 15:18             ` Marco Elver
2022-04-05  2:00             ` Hyeonggon Yoo
2022-04-05  2:00               ` Hyeonggon Yoo
2022-04-05 11:07               ` Marco Elver
2022-04-05 11:07                 ` Marco Elver
2022-04-05 22:47                 ` Hyeonggon Yoo [this message]
2022-04-05 22:47                   ` Hyeonggon Yoo
2022-04-06  8:34                   ` Marco Elver
2022-04-06  8:34                     ` Marco Elver
2022-04-06 11:50                     ` Hyeonggon Yoo
2022-04-06 11:50                       ` Hyeonggon Yoo
2022-04-06 12:15                       ` Marco Elver
2022-04-06 12:15                         ` Marco Elver
2022-04-06 12:31                         ` Hyeonggon Yoo
2022-04-06 12:31                           ` 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=YkzHG64zxu+nWbg3@hyeyoo \
    --to=42.hyeyoo@gmail.com \
    --cc=andreyknvl@google.com \
    --cc=elver@google.com \
    --cc=glittao@gmail.com \
    --cc=imran.f.khan@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=lkp@lists.01.org \
    --cc=oliver.sang@intel.com \
    --cc=qiang.zhang@windriver.com \
    --cc=thunder.leizhen@huawei.com \
    --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.