From patchwork Tue Aug 16 14:25:29 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marco Elver X-Patchwork-Id: 12945010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 35ACCC25B0E for ; Tue, 16 Aug 2022 14:25:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 50D7B8D0001; Tue, 16 Aug 2022 10:25:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4BC906B0075; Tue, 16 Aug 2022 10:25:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 384668D0001; Tue, 16 Aug 2022 10:25:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 28F316B0073 for ; Tue, 16 Aug 2022 10:25:49 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id F194B1610E8 for ; Tue, 16 Aug 2022 14:25:48 +0000 (UTC) X-FDA: 79805679576.28.EDFFB6E Received: from mail-ej1-f73.google.com (mail-ej1-f73.google.com [209.85.218.73]) by imf09.hostedemail.com (Postfix) with ESMTP id 7D8661401C8 for ; Tue, 16 Aug 2022 14:25:48 +0000 (UTC) Received: by mail-ej1-f73.google.com with SMTP id qb27-20020a1709077e9b00b0073160a55fd7so1853279ejc.17 for ; Tue, 16 Aug 2022 07:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:mime-version:message-id:date:from:to:cc; bh=hy9UEqt4hbmFGdzKrmujqIQhaC8w3Q92dlmS+f+lkQs=; b=nQ93mu+9MYBlAVVRshlJ2qiHdIT3FAlp3XTxCxOoApR/HIk3YecCcej73gcqPsmZpC Wo1BaRsiZ1VlI05iAjCzu9eC3ih6+EhuFw9Tlk1nbMmJTjI0F2ucwa7n1As53X3vdCZK adxnXbmSRHNUgqHpV9yTs/zYPnVLVDnp/L5MtUKqfiMS6eq3XkZnCz+eJmm1jWyHcN70 oZp5/OvdQWRgGPZkCAMnghcJ6jofS8ZHkL+nbfUde6ukenvSPj7OCdmHo7wvLVP3e8Hf UXZpG16wW0EeGksHK2EousEcoTBHPobx3CQheSaTWV5wFSCcTWe2o0w5mEldnFN1Ivxf ia6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:mime-version:message-id:date:x-gm-message-state :from:to:cc; bh=hy9UEqt4hbmFGdzKrmujqIQhaC8w3Q92dlmS+f+lkQs=; b=MmrOVUravcHVnPDdasJjgIlonGOywLXGF0GmIUajZgGUIoYa6GZYDPQhvc8/IOM/DW 46Yrhwc1qOpsHb+cKmU8FfPotnBfxLRVVp2YQ2cL0nlDjqf73QYERdr0uOmFoImCvZdo 8itD16CiDJh6Y9Grn8rzukwPZpfMka9pU1LOljl6Xw5vu9bdxSAEQ2fBV++jgbEw+hLb yfoyndYCII7KTC6yPIsdinWH6PkdTpsUTL4WyNC17JqBKCy0G9AW3+/VRvfRq4CrJa8P k31SqtbJAB5Fg9PZkBMuRqYiJWuHhQSgVzClG8/2yZMp6o5LKdtoiESflM4kKbiwjeG3 SOeQ== X-Gm-Message-State: ACgBeo0eNtL28Ojyv3MJt4Q/CSB5NnSjIETZwuZeypGOZVyUR7rUSwoh wj7KrKC00O0DmQgTzM1yOKytDIrObQ== X-Google-Smtp-Source: AA6agR4NrawCOqPWC6pOdWwNu471s80KRbfcN+j8Jq3jUxNPXYFC7pYpWjcXkV+7PgvXTxeCXJ7gCF+xbA== X-Received: from elver.muc.corp.google.com ([2a00:79e0:9c:201:b8f6:52b8:6a74:6073]) (user=elver job=sendgmr) by 2002:a05:6402:428a:b0:42e:8f7e:1638 with SMTP id g10-20020a056402428a00b0042e8f7e1638mr19083589edc.228.1660659946902; Tue, 16 Aug 2022 07:25:46 -0700 (PDT) Date: Tue, 16 Aug 2022 16:25:29 +0200 Message-Id: <20220816142529.1919543-1-elver@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.37.1.595.g718a3a8f04-goog Subject: [PATCH] kfence: free instead of ignore pool from kmemleak From: Marco Elver To: elver@google.com, Andrew Morton Cc: Alexander Potapenko , Dmitry Vyukov , kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Max Schulze , Will Deacon , Catalin Marinas , Yee Lee ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=nQ93mu+9; spf=pass (imf09.hostedemail.com: domain of 36qj7YgUKCEkpw6p2rzzrwp.nzxwty58-xxv6lnv.z2r@flex--elver.bounces.google.com designates 209.85.218.73 as permitted sender) smtp.mailfrom=36qj7YgUKCEkpw6p2rzzrwp.nzxwty58-xxv6lnv.z2r@flex--elver.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660659948; a=rsa-sha256; cv=none; b=g6jqP8jyfqMQW0UKlCs3xalY4RRaSlHFjOSItqrnwoxi47azgRvRV0mpHLPCWALhm+IWjr FX1ccslm1oiNc+6WkPLnZp13A5TSGLWJ91jaVKpxZyfsd21x2GXNAJKJzawBcgMgX0CzbH gHKkhbG+WAI25Aa4wqWoxDdKtEK2K/U= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660659948; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=hy9UEqt4hbmFGdzKrmujqIQhaC8w3Q92dlmS+f+lkQs=; b=MQUi4AsesxzpCnaTvdSwDYc7uSoHrDQDG6agfyyGNBW7X4DTTjSAV+i8VN8M3ac8AEKUGZ iVbGUh2UdwA7J7PKqg+xDaRG3afZNd450fDLc955doLmrnWYziIFsxkySVwSXiRhw+K5KZ 13Zkj6c9VsfCWk4c+FJ+5WXZpSVfwuM= X-Stat-Signature: 1z1485bjuayopas46r71n7srsnwfbabn X-Rspamd-Queue-Id: 7D8661401C8 X-Rspamd-Server: rspam08 Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=nQ93mu+9; spf=pass (imf09.hostedemail.com: domain of 36qj7YgUKCEkpw6p2rzzrwp.nzxwty58-xxv6lnv.z2r@flex--elver.bounces.google.com designates 209.85.218.73 as permitted sender) smtp.mailfrom=36qj7YgUKCEkpw6p2rzzrwp.nzxwty58-xxv6lnv.z2r@flex--elver.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-HE-Tag: 1660659948-230125 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: Due to recent changes to kmemleak and how memblock allocated memory is stored in the phys object tree of kmemleak, 07313a2b29ed ("mm: kfence: apply kmemleak_ignore_phys on early allocated pool") tried to fix KFENCE compatibility. KFENCE's memory can't simply be ignored, but must be freed completely due to it being handed out on slab allocations, and the slab post-alloc hook attempting to insert the object to the kmemleak object tree. Without this fix, reports like the below will appear during boot, and kmemleak is effectively rendered useless when KFENCE is enabled: | kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing) | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-v8-0815+ #5 | Hardware name: Raspberry Pi Compute Module 4 Rev 1.0 (DT) | Call trace: | dump_backtrace.part.0+0x1dc/0x1ec | show_stack+0x24/0x80 | dump_stack_lvl+0x8c/0xb8 | dump_stack+0x1c/0x38 | create_object.isra.0+0x490/0x4b0 | kmemleak_alloc+0x3c/0x50 | kmem_cache_alloc+0x2f8/0x450 | __proc_create+0x18c/0x400 | proc_create_reg+0x54/0xd0 | proc_create_seq_private+0x94/0x120 | init_mm_internals+0x1d8/0x248 | kernel_init_freeable+0x188/0x388 | kernel_init+0x30/0x150 | ret_from_fork+0x10/0x20 | kmemleak: Kernel memory leak detector disabled | kmemleak: Object 0xffffff806e24d000 (size 2097152): | kmemleak: comm "swapper", pid 0, jiffies 4294892296 | kmemleak: min_count = -1 | kmemleak: count = 0 | kmemleak: flags = 0x5 | kmemleak: checksum = 0 | kmemleak: backtrace: | kmemleak_alloc_phys+0x94/0xb0 | memblock_alloc_range_nid+0x1c0/0x20c | memblock_alloc_internal+0x88/0x100 | memblock_alloc_try_nid+0x148/0x1ac | kfence_alloc_pool+0x44/0x6c | mm_init+0x28/0x98 | start_kernel+0x178/0x3e8 | __primary_switched+0xc4/0xcc Reported-by: Max Schulze Fixes: 07313a2b29ed ("mm: kfence: apply kmemleak_ignore_phys on early allocated pool") Fixes: 0c24e061196c ("mm: kmemleak: add rbtree and store physical address for objects allocated with PA") Signed-off-by: Marco Elver Cc: Will Deacon Cc: Catalin Marinas Cc: Yee Lee --- Note: This easily reproduces on v5.19, but on 6.0-rc1 the issue is hidden by yet more kmemleak changes, but properly freeing the pool is the correct thing to do either way, given the post-alloc slab hooks. --- mm/kfence/core.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/mm/kfence/core.c b/mm/kfence/core.c index c252081b11df..9e52f2b87374 100644 --- a/mm/kfence/core.c +++ b/mm/kfence/core.c @@ -617,12 +617,13 @@ static bool __init kfence_init_pool_early(void) if (!addr) { /* - * The pool is live and will never be deallocated from this point on. - * Ignore the pool object from the kmemleak phys object tree, as it would - * otherwise overlap with allocations returned by kfence_alloc(), which - * are registered with kmemleak through the slab post-alloc hook. + * The pool is live and will never be deallocated from this + * point on. Remove the pool object from the kmemleak phys + * object tree, as it would otherwise overlap with allocations + * returned by kfence_alloc(), which are registered with + * kmemleak through the slab post-alloc hook. */ - kmemleak_ignore_phys(__pa(__kfence_pool)); + kmemleak_free_part_phys(__pa(__kfence_pool), KFENCE_POOL_SIZE); return true; }