From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 83098C433DB for ; Tue, 16 Mar 2021 18:19:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F3BF665115 for ; Tue, 16 Mar 2021 18:19:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F3BF665115 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3F7EA6B0036; Tue, 16 Mar 2021 14:19:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3A82B6B006C; Tue, 16 Mar 2021 14:19:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 26F516B006E; Tue, 16 Mar 2021 14:19:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0004.hostedemail.com [216.40.44.4]) by kanga.kvack.org (Postfix) with ESMTP id 0CE116B0036 for ; Tue, 16 Mar 2021 14:19:55 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id BA8FE180AD820 for ; Tue, 16 Mar 2021 18:19:54 +0000 (UTC) X-FDA: 77926551108.01.0B7EEEA Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf04.hostedemail.com (Postfix) with ESMTP id A48683F8 for ; Tue, 16 Mar 2021 18:19:51 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id F09A165116; Tue, 16 Mar 2021 18:19:40 +0000 (UTC) Date: Tue, 16 Mar 2021 18:19:38 +0000 From: Catalin Marinas To: Marco Elver Cc: Luis Henriques , Alexander Potapenko , Dmitry Vyukov , Andrew Morton , kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: Issue with kfence and kmemleak Message-ID: <20210316181938.GA28565@arm.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Stat-Signature: kiamzscrdzx51exehnqtm6pgfoxfj6eh X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: A48683F8 Received-SPF: none (kernel.org>: No applicable sender policy available) receiver=imf04; identity=mailfrom; envelope-from=""; helo=mail.kernel.org; client-ip=198.145.29.99 X-HE-DKIM-Result: none/none X-HE-Tag: 1615918791-235507 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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: > > This is probably a known issue, but just in case: looks like it's not > > possible to use kmemleak when kfence is enabled: > > > > [ 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? > > 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 > #include > #include > +#include > #include > #include > #include > @@ -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); I presume this pool does not refer any objects that are only tracked through pool pointers. kmemleak_free() (or *_free_part) should work, no need for the _phys variant (which converts it back with __va). Since we normally use kmemleak_ignore() (or no_scan) for objects we don't care about, I'd expand the comment that this object needs to be removed from the kmemleak object tree as it will overlap with subsequent allocations handled by kfence which return pointers within this range. -- Catalin