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