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=-19.8 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL 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 A6305C433DB for ; Tue, 16 Mar 2021 18:47:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 11FD465118 for ; Tue, 16 Mar 2021 18:47:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 11FD465118 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 97F9B6B0036; Tue, 16 Mar 2021 14:47:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 92FB86B006C; Tue, 16 Mar 2021 14:47:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 782096B006E; Tue, 16 Mar 2021 14:47:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0123.hostedemail.com [216.40.44.123]) by kanga.kvack.org (Postfix) with ESMTP id 5893A6B0036 for ; Tue, 16 Mar 2021 14:47:15 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 0F5E1180585D6 for ; Tue, 16 Mar 2021 18:47:15 +0000 (UTC) X-FDA: 77926620030.03.54831DD Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) by imf27.hostedemail.com (Postfix) with ESMTP id 7A36E801916F for ; Tue, 16 Mar 2021 18:47:12 +0000 (UTC) Received: by mail-wr1-f41.google.com with SMTP id e9so7975516wrw.10 for ; Tue, 16 Mar 2021 11:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=/z2fIfiSMbNLDzKmZ65SrMYqzt+vbhT5AuPhg7JmU1A=; b=rM3fdiR93sBuVsIUeAPdbUaLcSxhzpqK+Q3E4pVvgl1ggkrA4Fg5Ww3gaeX/Rtz3FR Zn8PL9Ieo8iIS9dWTjZ2KO8dFem4AgtBv+shAVHwk3zkRr4hI+bnRCHe30OO/KD1j/v9 zcV+oZaB2vEttpmraquxvw7W2uFx3vvWNuAVlSEMaz6HRefxpFtv+Z3Y+fxKA0dgsq1j UhATV7ovUa/r7Ka873Y0A70v2TtCtRHaB0bT42iHD9fZzVv5/zqkSCpuUWGQtReV3w8k OfiVLNQPw8M9SFLHxgqbpWCFdNGt6+155RuIug6fCxegjYlTsUfD3riqQ79j1kZwkdmx ooqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=/z2fIfiSMbNLDzKmZ65SrMYqzt+vbhT5AuPhg7JmU1A=; b=BP47hh3PRFyDzia8Sn+JugT97aeT4MYvEowXH8MAaIsISNgl+udInLDcYhnJcMaIaf FcX5z8a6EDw4BNdwQo1zRhvntGpBh7+j6SQfhiGsYqz0B9a4mPBB0Jsj16Sw3AKy7BrV v7mhmggR9BqvLC4P1j+O7UnDZ1pMVIQCZCzUloCnl4VktpahBuOkfEh054xXVCvPBoVj WWVzwM4U/0gyLaJ6Ex04qqbJsyFz265DQ+R1jmGnNoaR8ohGdHzaPNCmf+vPHxjs2t8+ U0TFO4FomPITx8M4u7hnVttkK+8oVEMQqwz92VOu19qTEgSOoNr8UzD0F5vB+LQ8e2wD Plgg== X-Gm-Message-State: AOAM5328gh0c3JA0dGPPYTnqdqS0zVbyTYOINmGCL+YlDsRuD3K3BwsJ psJKrNqIs66Ys1tHRH8FFr28yg== X-Google-Smtp-Source: ABdhPJyh+0bySp8rsXwvlCfrJY4z8ySax7xDgPD2zWP5JPV+1fSVVvyCXJOniHvdTY4W32t5qJ4HnA== X-Received: by 2002:adf:83c2:: with SMTP id 60mr438331wre.386.1615920430858; Tue, 16 Mar 2021 11:47:10 -0700 (PDT) Received: from elver.google.com ([2a00:79e0:15:13:1d09:9676:5eaa:550]) by smtp.gmail.com with ESMTPSA id 12sm191075wmw.43.2021.03.16.11.47.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Mar 2021 11:47:10 -0700 (PDT) Date: Tue, 16 Mar 2021 19:47:00 +0100 From: Marco Elver To: Catalin Marinas 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: References: <20210316181938.GA28565@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210316181938.GA28565@arm.com> User-Agent: Mutt/2.0.5 (2021-01-21) X-Stat-Signature: no6459mj8rrg77nqrnyggued6akq5k8u X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 7A36E801916F Received-SPF: none (google.com>: No applicable sender policy available) receiver=imf27; identity=mailfrom; envelope-from=""; helo=mail-wr1-f41.google.com; client-ip=209.85.221.41 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615920432-312752 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: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: > > > > > > [ 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. No, at this point this memory should not have been touched by anything. > kmemleak_free() (or *_free_part) should work, no need for the _phys > variant (which converts it back with __va). Will fix. > 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. One thing I've just run into: "BUG: KFENCE: out-of-bounds read in scan_block+0x6b/0x170 mm/kmemleak.c:1244" 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? I'd like kmemleak to scan the valid portion of an object allocated through KFENCE, but no further than that. Or do we need to fix the size if it's a kfence object: 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 #include +#include #include #include @@ -589,7 +590,7 @@ static struct kmemleak_object *create_object(unsigned long ptr, size_t size, atomic_set(&object->use_count, 1); object->flags = OBJECT_ALLOCATED; object->pointer = ptr; - object->size = size; + object->size = kfence_ksize((void *)ptr) ?: size; object->excess_ref = 0; object->min_count = min_count; object->count = 0; /* white color initially */ The alternative is to call kfence_ksize() in slab_post_alloc_hook() when calling kmemleak_alloc. Do you have a preference? Thanks, -- Marco