linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <cl@gentwo.de>
To: Feng Tang <feng.tang@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	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>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Dave Hansen <dave.hansen@intel.com>,
	Robin Murphy <robin.murphy@arm.com>,
	John Garry <john.garry@huawei.com>,
	Kefeng Wang <wangkefeng.wang@huawei.com>
Subject: Re: [PATCH v3 1/3] mm/slub: enable debugging memory wasting of kmalloc
Date: Wed, 27 Jul 2022 12:20:47 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.22.394.2207271214570.1205438@gentwo.de> (raw)
In-Reply-To: <20220727071042.8796-2-feng.tang@intel.com>

On Wed, 27 Jul 2022, Feng Tang wrote:

> @@ -2905,7 +2950,7 @@ static inline void *get_freelist(struct kmem_cache *s, struct slab *slab)
>   * already disabled (which is the case for bulk allocation).
>   */
>  static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node,
> -			  unsigned long addr, struct kmem_cache_cpu *c)
> +			  unsigned long addr, struct kmem_cache_cpu *c, unsigned int orig_size)
>  {
>  	void *freelist;
>  	struct slab *slab;
> @@ -3102,7 +3147,7 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node,
>   * pointer.
>   */
>  static void *__slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node,
> -			  unsigned long addr, struct kmem_cache_cpu *c)
> +			  unsigned long addr, struct kmem_cache_cpu *c, unsigned int orig_size)
>  {
>  	void *p;
>
> @@ -3115,7 +3160,7 @@ static void *__slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node,
>  	c = slub_get_cpu_ptr(s->cpu_slab);
>  #endif
>
> -	p = ___slab_alloc(s, gfpflags, node, addr, c);
> +	p = ___slab_alloc(s, gfpflags, node, addr, c, orig_size);
>  #ifdef CONFIG_PREEMPT_COUNT
>  	slub_put_cpu_ptr(s->cpu_slab);

This is modifying and making execution of standard slab functions more
expensive. Could you restrict modifications to the kmalloc subsystem?

kmem_cache_alloc() and friends are not doing any rounding up to power of
two  sizes.

What is happening here is that you pass kmalloc object size info through
the kmem_cache_alloc functions so that the regular allocation functions
debug functionality can then save the kmalloc specific object request
size. This is active even when no debugging options are enabled.

Can you avoid that? Have kmalloc do the object allocation without passing
through the kmalloc request size and then add the original size info
to the debug field later after execution continues in the kmalloc functions?



  reply	other threads:[~2022-07-27 10:21 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-27  7:10 [PATCH v3 0/3] mm/slub: some debug enhancements Feng Tang
2022-07-27  7:10 ` [PATCH v3 1/3] mm/slub: enable debugging memory wasting of kmalloc Feng Tang
2022-07-27 10:20   ` Christoph Lameter [this message]
2022-07-27 12:59     ` Feng Tang
2022-07-27 14:12     ` Vlastimil Babka
2022-07-27  7:10 ` [PATCH v3 2/3] mm/slub: only zero the requested size of buffer for kzalloc Feng Tang
2022-07-27  7:10 ` [PATCH v3 3/3] mm/slub: extend redzone check to cover extra allocated kmalloc space than requested Feng Tang
2022-07-31  6:53   ` [mm/slub] 3616799128: BUG_kmalloc-#(Not_tainted):kmalloc_Redzone_overwritten kernel test robot
2022-07-31  8:16     ` Feng Tang
2022-08-01  6:21       ` Feng Tang
2022-08-01  7:26         ` Dmitry Vyukov
2022-08-01  7:48           ` Feng Tang
2022-08-01  8:13             ` Christoph Lameter
2022-08-01 14:23         ` Vlastimil Babka
2022-08-02  6:54           ` Feng Tang
2022-08-02  7:06             ` Dmitry Vyukov
2022-08-02  7:46               ` Feng Tang
2022-08-02  7:59                 ` Dmitry Vyukov
2022-08-02  8:44                   ` Feng Tang
2022-08-02  9:43               ` Vlastimil Babka
2022-08-02 10:30                 ` Dmitry Vyukov
2022-08-02 13:36                   ` Feng Tang
2022-08-02 14:38                     ` Dmitry Vyukov
2022-08-04  6:28                       ` Feng Tang
2022-08-04 10:47                         ` Dmitry Vyukov
2022-08-04 12:22                           ` Feng Tang
2022-08-15  7:27                             ` Feng Tang
2022-08-16 13:27                               ` Oliver Sang
2022-08-16 14:12                                 ` Feng Tang
2022-08-02 10:31                 ` Dmitry Vyukov
2022-08-02  6:59           ` Dmitry Vyukov

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=alpine.DEB.2.22.394.2207271214570.1205438@gentwo.de \
    --to=cl@gentwo.de \
    --cc=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=dave.hansen@intel.com \
    --cc=feng.tang@intel.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=john.garry@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=robin.murphy@arm.com \
    --cc=roman.gushchin@linux.dev \
    --cc=vbabka@suse.cz \
    --cc=wangkefeng.wang@huawei.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).