On Wed, Jul 05, 2023 at 03:19:06PM +0200, Andrey Konovalov wrote: > On Wed, Jul 5, 2023 at 2:51 PM Marco Elver <elver@xxxxxxxxxx> wrote: > > > > On Wed, 5 Jul 2023 at 14:44, <andrey.konovalov@xxxxxxxxx> wrote: > > > > > > From: Andrey Konovalov <andreyknvl@xxxxxxxxxx> > > > > > > Commit 946fa0dbf2d8 ("mm/slub: extend redzone check to extra allocated > > > kmalloc space than requested") added precise kmalloc redzone poisoning > > > to the slub_debug functionality. > > > > > > However, this commit didn't account for HW_TAGS KASAN fully initializing > > > the object via its built-in memory initialization feature. Even though > > > HW_TAGS KASAN memory initialization contains special memory initialization > > > handling for when slub_debug is enabled, it does not account for in-object > > > slub_debug redzones. As a result, HW_TAGS KASAN can overwrite these > > > redzones and cause false-positive slub_debug reports. > > > > > > To fix the issue, avoid HW_TAGS KASAN memory initialization when slub_debug > > > is enabled altogether. Implement this by moving the __slub_debug_enabled > > > check to slab_post_alloc_hook. Common slab code seems like a more > > > appropriate place for a slub_debug check anyway. > > > > > > Fixes: 946fa0dbf2d8 ("mm/slub: extend redzone check to extra allocated kmalloc space than requested") > > > Cc: <stable@xxxxxxxxxxxxxxx> > > > Reported-by: Mark Rutland <mark.rutland@xxxxxxx> > > > > Is it fixing this issue: > > > > https://lore.kernel.org/all/20230628154714.GB22090@willie-the-truck/ > > Yes, my bad, messed up the Reported-by tag. The correct one should be: > > Reported-by: Will Deacon <will@xxxxxxxxxx> > > > Other than the question above, it looks sane: > > > > Acked-by: Marco Elver <elver@xxxxxxxxxx> > > Thank you, Marco! Cheers, this seems to fix the splats for me: Tested-by: Will Deacon <will@xxxxxxxxxx> Will