Re: [mm/slub] 555b8c8cb3: WARNING:at_lib/stackdepot.c:#stack_depot_fetch

[Marco Elver]

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@xxxxxxx> 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.

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

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 ------