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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DB88FC25B0E for ; Tue, 16 Aug 2022 16:20:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1DCCD6B0073; Tue, 16 Aug 2022 12:20:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 18BD88D0001; Tue, 16 Aug 2022 12:20:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 053F06B0078; Tue, 16 Aug 2022 12:20:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id EA4A16B0073 for ; Tue, 16 Aug 2022 12:20:33 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id BD0D2C032B for ; Tue, 16 Aug 2022 16:20:33 +0000 (UTC) X-FDA: 79805968746.21.FBE5FE7 Received: from mail-yw1-f169.google.com (mail-yw1-f169.google.com [209.85.128.169]) by imf09.hostedemail.com (Postfix) with ESMTP id 650AB1401CD for ; Tue, 16 Aug 2022 16:20:33 +0000 (UTC) Received: by mail-yw1-f169.google.com with SMTP id 00721157ae682-3246910dac3so164388577b3.12 for ; Tue, 16 Aug 2022 09:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=TmDmP2Yh2xB0Nw2rEpzh522PfockFUs65PSBK5ilao8=; b=D6VUDRfgjEV6Oks3BCMPo1Apiv37NO/4LwPweuPco56VlT8Dkpc15yJYPfe0l88epI jtDgcRRvopVpCNGyxxgN6islo0+kLYv1D2pbOSO1Z0dmBLVZqXVqYmjGrUYHdqp+83+R qgO/IqoYiwhEXfQiUSH97ZhgPbUqURr/WKnMAZ/mtB6I4KQJocTq8UzGUuXu3pyLjCab DeU96vs0H5pk8wSU5eVOiaOVgtqzw4eHeQAj1bUu65G3GgHfvH92V9Z0/4f5Z6WYV0uj Io2kCdpzhTBWwSVWiwlvJm7mwpRYXi7c/gaQYAZD6qZXpw9MSf8JAreaxWigfNad/2db urBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=TmDmP2Yh2xB0Nw2rEpzh522PfockFUs65PSBK5ilao8=; b=u+QZvyoNAAxvTNkYHWYoezuX6yLmIJCz7Ef0BYkXu21ab+jG3/ykhIzZ+yr0SONYDr T/J3ni8xJBi5sjJejnwlWUEpE6vL0MoXORv61Kex5J+7RyM+oIMhDhzT1paEFbH6IVXV sPAtMxpISuVLalYxQmsJUTG7M3PI3ldEdpmHx7HoAtYOLgWZnIoenHZrg5SmdCXLLvFs jwMP3BerBMDmbQgkk3E+XO8JyOkpBzj81qp/B5S8CqkKgJpe8pegcXZCrmJqw6utoT8F QKMUIYX5+VpcUwX1urpjLFr2q24eXlLi/fRaqNEF3DS1go1prbd0cL6dvhwgN5kC42ls Qpzg== X-Gm-Message-State: ACgBeo1yVt00rwSZmQ8FBoQdyLOGLmlffeK/XdEZYMx38mgX1PiJlgM2 8hcaJnPzfANdvJOIoLBm+jdabLm5/qf/OTQK7/InnQ== X-Google-Smtp-Source: AA6agR5qmdXdoZCr+yGPN5qQTVnWFQA2x8Hha+7gFg1IeaJ8AIbHz2A3vmkKZRhZChq8hd/F8cICoN5YPl8eTT/Bo98= X-Received: by 2002:a25:828c:0:b0:68f:6fd6:56b3 with SMTP id r12-20020a25828c000000b0068f6fd656b3mr1106642ybk.611.1660666832507; Tue, 16 Aug 2022 09:20:32 -0700 (PDT) MIME-Version: 1.0 References: <20220816142529.1919543-1-elver@google.com> In-Reply-To: <20220816142529.1919543-1-elver@google.com> From: Marco Elver Date: Tue, 16 Aug 2022 18:19:56 +0200 Message-ID: Subject: Re: [PATCH] kfence: free instead of ignore pool from kmemleak 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 Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660666833; a=rsa-sha256; cv=none; b=hepMcsGF1LVe/7mHPhPAcrRPYixv80UDbeVrRcur6VV0t1J5f+ZcavxfkQNsebARqEyPpa 78h34mOKw/px8m68b5uph+NBwNtxAAcGKpJnpaHpCYyrnKDcMRnguBZ8AyP7iRYDulsK4K rWBsu6itnQ34Cn/cwlwG/Xwfjjd/9h8= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=D6VUDRfg; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of elver@google.com designates 209.85.128.169 as permitted sender) smtp.mailfrom=elver@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660666833; 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:in-reply-to:references:references:dkim-signature; bh=TmDmP2Yh2xB0Nw2rEpzh522PfockFUs65PSBK5ilao8=; b=d2nVuckkmtqFUVBpqTps0nKK6Ks+QR+ZVHIde5E4YS4qy+wZOSjR+D95IQ2GcbvyMLPK1W sr49eGa+m7GG64xx+5CO9ZJL0AwEkKSatlK8kJUYkjHUrStCKiBLVS0HPcGaDT/baOMjZG NqGsuJRygCLhS3zIl3dJDKrw2OAhWtg= X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 650AB1401CD X-Rspam-User: Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=D6VUDRfg; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of elver@google.com designates 209.85.128.169 as permitted sender) smtp.mailfrom=elver@google.com X-Stat-Signature: pu7z8qzm9sumx8kehnwarr3gq6pgtmq4 X-HE-Tag: 1660666833-112725 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: Per Catalin's comment in https://lore.kernel.org/all/Yvu4bBmykYr+0CXk@arm.com/T/#u this patch should be ignored, because 6.0-rc1 is fine. We just have to fix 5.19 by reverting 07313a2b29ed from it. On Tue, 16 Aug 2022 at 16:25, Marco Elver wrote: > > 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; > } > > -- > 2.37.1.595.g718a3a8f04-goog >