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=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,UNPARSEABLE_RELAY 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 EA1B4C433DB for ; Wed, 17 Mar 2021 08:39:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2F6E964E28 for ; Wed, 17 Mar 2021 08:39:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2F6E964E28 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B555D6B0070; Wed, 17 Mar 2021 04:39:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B2E446B0071; Wed, 17 Mar 2021 04:39:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A1EA36B0073; Wed, 17 Mar 2021 04:39:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0205.hostedemail.com [216.40.44.205]) by kanga.kvack.org (Postfix) with ESMTP id 8403E6B0070 for ; Wed, 17 Mar 2021 04:39:56 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 30A6F8249980 for ; Wed, 17 Mar 2021 08:39:56 +0000 (UTC) X-FDA: 77928718392.20.F0B642D Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf13.hostedemail.com (Postfix) with ESMTP id 76C16E0001B4 for ; Wed, 17 Mar 2021 08:39:55 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 0AB47AE47; Wed, 17 Mar 2021 08:39:54 +0000 (UTC) Received: from localhost (brahms [local]) by brahms (OpenSMTPD) with ESMTPA id 090c966d; Wed, 17 Mar 2021 08:41:08 +0000 (UTC) Date: Wed, 17 Mar 2021 08:41:08 +0000 From: Luis Henriques To: Marco Elver Cc: Catalin Marinas , 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: References: <20210316181938.GA28565@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: X-Stat-Signature: gdn9zcyegcaqzqax7k6shztgm7gg5cf8 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 76C16E0001B4 Received-SPF: none (suse.de>: No applicable sender policy available) receiver=imf13; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: none/none X-HE-Tag: 1615970395-564052 Content-Transfer-Encoding: quoted-printable 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 07:47:00PM +0100, Marco Elver wrote: > On Tue, Mar 16, 2021 at 06:19PM +0000, Catalin Marinas wrote: > > 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: > > > >=20 > > > > [ 0.272136] kmemleak: Cannot insert 0xffff888236e02f00 into th= e object search tree (overlaps existing) > > > > [ 0.272136] CPU: 0 PID: 8 Comm: kthreadd Not tainted 5.12.0-rc= 3+ #92 > > > > [ 0.272136] Hardware name: QEMU Standard PC (i440FX + PIIX, 19= 96), 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 4294892= 296 > > > > [ 0.272136] kmemleak: min_count =3D 0 > > > > [ 0.272136] kmemleak: count =3D 0 > > > > [ 0.272136] kmemleak: flags =3D 0x1 > > > > [ 0.272136] kmemleak: checksum =3D 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 > > > >=20 > > > > 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 initialise= d > > > > *before* kmemleak. > > > >=20 > > > > 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) > > > > =20 > > > > if (!__kfence_pool) > > > > pr_err("failed to allocate pool\n"); > > > > + kmemleak_no_scan(__kfence_pool); > > > > } > > >=20 > > > Can you try the below patch? > > >=20 > > > Thanks, > > > -- Marco > > >=20 > > > ------ >8 ------ > > >=20 > > > 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 +=3D 2 * PAGE_SIZE; > > > } > > > =20 > > > + /* > > > + * The pool is live and will never be deallocated from this point= on; > > > + * tell kmemleak this is now free memory, so that later allocatio= ns can > > > + * correctly be tracked. > > > + */ > > > + kmemleak_free_part_phys(__pa(__kfence_pool), KFENCE_POOL_SIZE); > >=20 > > I presume this pool does not refer any objects that are only tracked > > through pool pointers. >=20 > No, at this point this memory should not have been touched by anything. >=20 > > kmemleak_free() (or *_free_part) should work, no need for the _phys > > variant (which converts it back with __va). >=20 > Will fix. >=20 > > 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 subsequ= ent > > allocations handled by kfence which return pointers within this range= . >=20 > One thing I've just run into: "BUG: KFENCE: out-of-bounds read in > scan_block+0x6b/0x170 mm/kmemleak.c:1244" FWIW, I just saw this as well. It doesn't happen every time, but yeah I missed it in my initial testing. Cheers, -- Lu=EDs >=20 > Probably because kmemleak is passed the rounded size for the size-class= , > and not the real allocation size. Can this be fixed with > kmemleak_ignore() only called on the KFENCE guard pages? >=20 > I'd like kmemleak to scan the valid portion of an object allocated > through KFENCE, but no further than that. >=20 > Or do we need to fix the size if it's a kfence object: >=20 > diff --git a/mm/kmemleak.c b/mm/kmemleak.c > index c0014d3b91c1..fe6e3ae8e8c6 100644 > --- a/mm/kmemleak.c > +++ b/mm/kmemleak.c > @@ -97,6 +97,7 @@ > #include > =20 > #include > +#include > #include > #include > =20 > @@ -589,7 +590,7 @@ static struct kmemleak_object *create_object(unsign= ed long ptr, size_t size, > atomic_set(&object->use_count, 1); > object->flags =3D OBJECT_ALLOCATED; > object->pointer =3D ptr; > - object->size =3D size; > + object->size =3D kfence_ksize((void *)ptr) ?: size; > object->excess_ref =3D 0; > object->min_count =3D min_count; > object->count =3D 0; /* white color initially */ >=20 >=20 > The alternative is to call kfence_ksize() in slab_post_alloc_hook() whe= n > calling kmemleak_alloc. >=20 > Do you have a preference? >=20 > Thanks, > -- Marco