From: Feng Tang <feng.tang@intel.com>
To: Hyeonggon Yoo <42.hyeyoo@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>,
"Dmitry Vyukov" <dvyukov@google.com>,
"Hansen, Dave" <dave.hansen@intel.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
"John Garry" <john.garry@huawei.com>,
Kefeng Wang <wangkefeng.wang@huawei.com>
Subject: Re: [PATCH v4 1/4] mm/slub: enable debugging memory wasting of kmalloc
Date: Sun, 4 Sep 2022 17:42:33 +0800 [thread overview]
Message-ID: <YxRzCX8WqOv3KESJ@feng-clx> (raw)
In-Reply-To: <YxRp5uz9KSY0S9id@hyeyoo>
On Sun, Sep 04, 2022 at 05:03:34PM +0800, Hyeonggon Yoo wrote:
[...]
> > >
> > > This patch is okay but with patch 4, init_object() initializes redzone/poison area
> > > using s->object_size, and init_kmalloc_object() fixes redzone/poison area using orig_size.
> > > Why not do it in init_object() in the first time?
> > >
> > > Also, updating redzone/poison area after alloc_single_from_new_slab()
> > > (outside list_lock, after adding slab to list) will introduce races with validation.
> > >
> > > So I think doing set_orig_size()/init_kmalloc_object() in alloc_debug_processing() would make more sense.
> >
> > Yes, this makes sense, and in v3, kmalloc redzone/poison setup was
> > done in alloc_debug_processing() (through init_object()). When
> > rebasing to v4, I met the classical problem: how to pass 'orig_size'
> > parameter :)
> >
> > In latest 'for-next' branch, one call path for alloc_debug_processing()
> > is
> > ___slab_alloc
> > get_partial
> > get_any_partial
> > get_partial_node
> > alloc_debug_processing
> >
> > Adding 'orig_size' paramter to all these function looks horrible, and
> > I couldn't figure out a good way and chosed to put those ops after
> > 'set_track()'
>
> IMO adding a parameter to them isn't too horrible...
> I don't see better solution than adding a parameter with current implementation.
> (Yeah, the code is quite complicated...)
>
> It won't affect performance to meaningful degree as most of
> allocations will be served from cpu slab or percpu partial list.
Thanks for the suggestion! I'm fine with it and just afraid other
developers may dislike the extra parameter.
The race condition you mentioned is a valid concern, and I have thought
about it, one way is moving the set_orig_size() after the redzone/poision
setup, and in 'check_object()' we can detect whether the 'orig_size' is
set, and skip that check if it's not set yet. As the manual validate_slab
triggered from sysfs interface is a rare debug activity, I think skipping
one object shouldn't hurt much.
Thanks,
Feng
> --
> Thanks,
> Hyeonggon
>
next prev parent reply other threads:[~2022-09-04 9:43 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-29 7:56 [PATCH v4 0/4] mm/slub: some debug enhancements for kmalloc objects Feng Tang
2022-08-29 7:56 ` [PATCH v4 1/4] mm/slub: enable debugging memory wasting of kmalloc Feng Tang
2022-08-31 14:52 ` Hyeonggon Yoo
2022-09-01 5:04 ` Feng Tang
2022-09-01 11:14 ` Hyeonggon Yoo
2022-09-01 14:01 ` Hyeonggon Yoo
2022-09-02 6:15 ` Feng Tang
2022-09-04 9:03 ` Hyeonggon Yoo
2022-09-04 9:42 ` Feng Tang [this message]
2022-09-04 10:58 ` Hyeonggon Yoo
2022-09-05 2:55 ` Feng Tang
2022-09-05 6:29 ` Vlastimil Babka
2022-09-05 7:06 ` Feng Tang
2022-09-05 7:33 ` Vlastimil Babka
2022-09-05 8:37 ` Feng Tang
2022-09-06 13:39 ` Hyeonggon Yoo
2022-08-29 7:56 ` [PATCH v4 2/4] mm/slub: only zero the requested size of buffer for kzalloc Feng Tang
2022-08-29 7:56 ` [PATCH v4 3/4] mm: kasan: Add free_meta size info in struct kasan_cache Feng Tang
2022-08-29 7:56 ` [PATCH v4 4/4] mm/slub: extend redzone check to cover extra allocated kmalloc space than requested Feng Tang
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=YxRzCX8WqOv3KESJ@feng-clx \
--to=feng.tang@intel.com \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=dave.hansen@intel.com \
--cc=dvyukov@google.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).