From: Andrey Konovalov <[email protected]>
Commit 29d7355a9d05 ("kasan: save alloc stack traces for mempool") messed
up one of the calls to unpoison_slab_object: the last two arguments are
supposed to be GFP flags and whether to init the object memory.
Fix the call.
Without this fix, unpoison_slab_object provides the object's size as
GFP flags to unpoison_slab_object, which can cause LOCKDEP reports
(and probably other issues).
Fixes: 29d7355a9d05 ("kasan: save alloc stack traces for mempool")
Reported-by: Brad Spengler <[email protected]>
Signed-off-by: Andrey Konovalov <[email protected]>
---
mm/kasan/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index e7c9a4dc89f8..85e7c6b4575c 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -532,7 +532,7 @@ void __kasan_mempool_unpoison_object(void *ptr, size_t size, unsigned long ip)
return;
/* Unpoison the object and save alloc info for non-kmalloc() allocations. */
- unpoison_slab_object(slab->slab_cache, ptr, size, flags);
+ unpoison_slab_object(slab->slab_cache, ptr, flags, false);
/* Poison the redzone and save alloc info for kmalloc() allocations. */
if (is_kmalloc_cache(slab->slab_cache))
--
2.25.1
On Fri, 14 Jun 2024 at 16:16, <[email protected]> wrote:
>
> From: Andrey Konovalov <[email protected]>
>
> Commit 29d7355a9d05 ("kasan: save alloc stack traces for mempool") messed
> up one of the calls to unpoison_slab_object: the last two arguments are
> supposed to be GFP flags and whether to init the object memory.
>
> Fix the call.
>
> Without this fix, unpoison_slab_object provides the object's size as
> GFP flags to unpoison_slab_object, which can cause LOCKDEP reports
> (and probably other issues).
>
> Fixes: 29d7355a9d05 ("kasan: save alloc stack traces for mempool")
> Reported-by: Brad Spengler <[email protected]>
> Signed-off-by: Andrey Konovalov <[email protected]>
Oof.
Acked-by: Marco Elver <[email protected]>
mm needs explicit Cc: stable, right? If so, we better add Cc: stable as well.
> ---
> mm/kasan/common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> index e7c9a4dc89f8..85e7c6b4575c 100644
> --- a/mm/kasan/common.c
> +++ b/mm/kasan/common.c
> @@ -532,7 +532,7 @@ void __kasan_mempool_unpoison_object(void *ptr, size_t size, unsigned long ip)
> return;
>
> /* Unpoison the object and save alloc info for non-kmalloc() allocations. */
> - unpoison_slab_object(slab->slab_cache, ptr, size, flags);
> + unpoison_slab_object(slab->slab_cache, ptr, flags, false);
>
> /* Poison the redzone and save alloc info for kmalloc() allocations. */
> if (is_kmalloc_cache(slab->slab_cache))
> --
> 2.25.1
>
On Fri, Jun 14, 2024 at 4:29 PM Marco Elver <[email protected]> wrote:
>
> On Fri, 14 Jun 2024 at 16:16, <[email protected]> wrote:
> >
> > From: Andrey Konovalov <[email protected]>
> >
> > Commit 29d7355a9d05 ("kasan: save alloc stack traces for mempool") messed
> > up one of the calls to unpoison_slab_object: the last two arguments are
> > supposed to be GFP flags and whether to init the object memory.
> >
> > Fix the call.
> >
> > Without this fix, unpoison_slab_object provides the object's size as
> > GFP flags to unpoison_slab_object, which can cause LOCKDEP reports
> > (and probably other issues).
> >
> > Fixes: 29d7355a9d05 ("kasan: save alloc stack traces for mempool")
> > Reported-by: Brad Spengler <[email protected]>
> > Signed-off-by: Andrey Konovalov <[email protected]>
>
> Oof.
>
> Acked-by: Marco Elver <[email protected]>
>
> mm needs explicit Cc: stable, right? If so, we better add Cc: stable as well.
Makes sense, sent v2 with CC stable and a commit message fix.
Thanks!