lkml.org 
[lkml]   [2022]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [mm/slub] 555b8c8cb3: WARNING:at_lib/stackdepot.c:#stack_depot_fetch
On 4/4/22 10:10, Marco Elver wrote:
> On Mon, Apr 04, 2022 at 12:05PM +0900, Hyeonggon Yoo wrote:
> (Maybe CONFIG_KCSAN_STRICT=y is going to yield something? I still doubt
> it thought, this bug is related to corrupted stackdepot handle
> somewhere...)
>
>> I noticed that it is not reproduced when KASAN=y and KFENCE=n (reproduced 0 of 181).
>> and it was reproduced 56 of 196 when KASAN=n and KFENCE=y
>>
>> maybe this issue is related to kfence?

Hmm kfence seems to be a good lead. If I understand kfence_guarded_alloc()
correctly, it tries to set up something that really looks like a normal slab
page? Especially the part with comment /* Set required slab fields. */
But it doesn't seem to cover the debugging parts that SLUB sets up with
alloc_debug_processing(). This includes alloc stack saving, thus, after
commit 555b8c8cb3, a stackdepot handle setting. It probably normally doesn't
matter as is_kfence_address() redirects processing of kfence-allocated
objects so we don't hit any slub code that expects the debugging parts to be
properly initialized.

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?

> What about KASAN=n and KFENCE=n?
>
> Thanks,
> -- Marco

\
 
 \ /
  Last update: 2022-04-04 16:21    [W:0.083 / U:2.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site