From: Luis Henriques <lhenriques@suse.de>
To: Marco Elver <elver@google.com>
Cc: Alexander Potapenko <glider@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Andrew Morton <akpm@linux-foundation.org>,
kasan-dev@googlegroups.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: Issue with kfence and kmemleak
Date: Tue, 16 Mar 2021 17:42:20 +0000 [thread overview]
Message-ID: <YFDt/PunpQydUAq/@suse.de> (raw)
In-Reply-To: <YFDrGL45JxFHyajD@elver.google.com>
On Tue, Mar 16, 2021 at 06:30:00PM +0100, Marco Elver wrote:
> On Tue, Mar 16, 2021 at 04:42PM +0000, Luis Henriques wrote:
> > Hi!
> >
> > This is probably a known issue, but just in case: looks like it's not
> > possible to use kmemleak when kfence is enabled:
>
> Thanks for spotting this.
>
> > [ 0.272136] kmemleak: Cannot insert 0xffff888236e02f00 into the object search tree (overlaps existing)
> > [ 0.272136] CPU: 0 PID: 8 Comm: kthreadd Not tainted 5.12.0-rc3+ #92
> > [ 0.272136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014
> > [ 0.272136] Call Trace:
> > [ 0.272136] dump_stack+0x6d/0x89
> > [ 0.272136] create_object.isra.0.cold+0x40/0x62
> > [ 0.272136] ? process_one_work+0x5a0/0x5a0
> > [ 0.272136] ? process_one_work+0x5a0/0x5a0
> > [ 0.272136] kmem_cache_alloc_trace+0x110/0x2f0
> > [ 0.272136] ? process_one_work+0x5a0/0x5a0
> > [ 0.272136] kthread+0x3f/0x150
> > [ 0.272136] ? lockdep_hardirqs_on_prepare+0xd4/0x170
> > [ 0.272136] ? __kthread_bind_mask+0x60/0x60
> > [ 0.272136] ret_from_fork+0x22/0x30
> > [ 0.272136] kmemleak: Kernel memory leak detector disabled
> > [ 0.272136] kmemleak: Object 0xffff888236e00000 (size 2097152):
> > [ 0.272136] kmemleak: comm "swapper", pid 0, jiffies 4294892296
> > [ 0.272136] kmemleak: min_count = 0
> > [ 0.272136] kmemleak: count = 0
> > [ 0.272136] kmemleak: flags = 0x1
> > [ 0.272136] kmemleak: checksum = 0
> > [ 0.272136] kmemleak: backtrace:
> > [ 0.272136] memblock_alloc_internal+0x6d/0xb0
> > [ 0.272136] memblock_alloc_try_nid+0x6c/0x8a
> > [ 0.272136] kfence_alloc_pool+0x26/0x3f
> > [ 0.272136] start_kernel+0x242/0x548
> > [ 0.272136] secondary_startup_64_no_verify+0xb0/0xbb
> >
> > I've tried the hack below but it didn't really helped. Obviously I don't
> > really understand what's going on ;-) But I think the reason for this
> > patch not working as (I) expected is because kfence is initialised
> > *before* kmemleak.
> >
> > diff --git a/mm/kfence/core.c b/mm/kfence/core.c
> > index 3b8ec938470a..b4ffd7695268 100644
> > --- a/mm/kfence/core.c
> > +++ b/mm/kfence/core.c
> > @@ -631,6 +631,9 @@ void __init kfence_alloc_pool(void)
> >
> > if (!__kfence_pool)
> > pr_err("failed to allocate pool\n");
> > + kmemleak_no_scan(__kfence_pool);
> > }
>
> Can you try the below patch?
Yep, that seems to fix the issue. Feel free to add my Tested-by. Thanks!
Cheers,
--
Luís
>
> Thanks,
> -- Marco
>
> ------ >8 ------
>
> diff --git a/mm/kfence/core.c b/mm/kfence/core.c
> index f7106f28443d..5891019721f6 100644
> --- a/mm/kfence/core.c
> +++ b/mm/kfence/core.c
> @@ -12,6 +12,7 @@
> #include <linux/debugfs.h>
> #include <linux/kcsan-checks.h>
> #include <linux/kfence.h>
> +#include <linux/kmemleak.h>
> #include <linux/list.h>
> #include <linux/lockdep.h>
> #include <linux/memblock.h>
> @@ -481,6 +482,13 @@ static bool __init kfence_init_pool(void)
> addr += 2 * PAGE_SIZE;
> }
>
> + /*
> + * The pool is live and will never be deallocated from this point on;
> + * tell kmemleak this is now free memory, so that later allocations can
> + * correctly be tracked.
> + */
> + kmemleak_free_part_phys(__pa(__kfence_pool), KFENCE_POOL_SIZE);
> +
> return true;
>
> err:
next prev parent reply other threads:[~2021-03-16 17:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-16 16:42 Issue with kfence and kmemleak Luis Henriques
2021-03-16 17:30 ` Marco Elver
2021-03-16 17:42 ` Luis Henriques [this message]
2021-03-16 18:19 ` Catalin Marinas
2021-03-16 18:47 ` Marco Elver
2021-03-16 19:22 ` Catalin Marinas
2021-03-17 8:41 ` Luis Henriques
2021-03-17 8:48 ` Marco Elver
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YFDt/PunpQydUAq/@suse.de \
--to=lhenriques@suse.de \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.