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 E2D0FC25B08 for ; Wed, 17 Aug 2022 17:24:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 85A346B0074; Wed, 17 Aug 2022 13:24:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 808056B0075; Wed, 17 Aug 2022 13:24:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6D03C8D0001; Wed, 17 Aug 2022 13:24:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 5F7F96B0074 for ; Wed, 17 Aug 2022 13:24:08 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 37705160F51 for ; Wed, 17 Aug 2022 17:24:08 +0000 (UTC) X-FDA: 79809757776.17.D728161 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf08.hostedemail.com (Postfix) with ESMTP id A03C4160064 for ; Wed, 17 Aug 2022 17:24:07 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 6E5C2B81DA0; Wed, 17 Aug 2022 17:24:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D310CC433C1; Wed, 17 Aug 2022 17:24:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660757045; bh=uLROoJKIJ0weoDRW5FA5gDN9QKs92dcOkfsSGEFYP8E=; h=Subject:To:Cc:From:Date:In-Reply-To:From; b=iIm9aMtJFyqn+pj0lbfGMnZvuT0ir7MIhpwHpK2GaLn/l8Faz7u7LiRZXOy0kcUhq KyKhDzZrPUwOhMyeNnuIU03dI+guV6ToX2LtmqOJhBW850BDYWnfU411qKqZhEszBJ p84Oy5QlwHWMCsQ1Tl6CX+G8k4BkJTZGOgKDJT3w= Subject: Patch "Revert "mm: kfence: apply kmemleak_ignore_phys on early allocated pool"" has been added to the 5.19-stable tree To: akpm@linux-foundation.org,catalin.marinas@arm.com,dvyukov@google.com,elver@google.com,glider@google.com,gregkh@linuxfoundation.org,kasan-dev@googlegroups.com,linux-mm@kvack.org,max.schulze@online.de,will@kernel.org,yee.lee@mediatek.com Cc: From: Date: Wed, 17 Aug 2022 19:24:02 +0200 In-Reply-To: <20220816163641.2359996-1-elver@google.com> Message-ID: <166075704210791@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit X-stable: commit X-Patchwork-Hint: ignore ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660757047; a=rsa-sha256; cv=none; b=F75SWrlUDnd4q1kaiROUp2hkxFuJdYaO/azxPKhweo9FT3Dw3ZzkRhDDs2iLzbF5tSkWyh IBy+Baa/YIdao5xAZMgZC3d674tuuEY2MXMyn0ELoIn1Vj8orOyI2hBX9CegVFnEqt3Axj oBgqWcD53gTO3GBZxD+utfv/U7syXqU= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=iIm9aMtJ; spf=pass (imf08.hostedemail.com: domain of gregkh@linuxfoundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org; dmarc=pass (policy=none) header.from=linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660757047; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:dkim-signature; bh=HEoNIlbqrQu8nJsTxhRPIAjN1F9b+gPXw1FAJpTsUZU=; b=EheQ06FODNcEVea5xIc6VZQfUaj12r5WV4oFDcIt3w0h57QXdK2YfC4SSRqU//4wejvvsq 9+i0fLnhcZAUB+My4wv/VWKAbV4Ll4TDgYB6Qargr2xaRkk7DZZ4/XfFeW6eIm1AFCPAqM AVuOtH9srnclFcdTF/TtnegPPHtSSOM= Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=iIm9aMtJ; spf=pass (imf08.hostedemail.com: domain of gregkh@linuxfoundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org; dmarc=pass (policy=none) header.from=linuxfoundation.org X-Rspamd-Server: rspam05 X-Rspam-User: X-Stat-Signature: sarntoge3a1jgwx169jbudeec6rbqmrg X-Rspamd-Queue-Id: A03C4160064 X-HE-Tag: 1660757047-353305 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: This is a note to let you know that I've just added the patch titled Revert "mm: kfence: apply kmemleak_ignore_phys on early allocated pool" to the 5.19-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: revert-mm-kfence-apply-kmemleak_ignore_phys-on-early-allocated-pool.patch and it can be found in the queue-5.19 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >From elver@google.com Wed Aug 17 19:23:19 2022 From: Marco Elver Date: Tue, 16 Aug 2022 18:36:41 +0200 Subject: Revert "mm: kfence: apply kmemleak_ignore_phys on early allocated pool" To: elver@google.com, stable@vger.kernel.org, Greg Kroah-Hartman Cc: Alexander Potapenko , Dmitry Vyukov , Andrew Morton , kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Will Deacon , Catalin Marinas , Yee Lee , Max Schulze Message-ID: <20220816163641.2359996-1-elver@google.com> From: Marco Elver This reverts commit 07313a2b29ed1079eaa7722624544b97b3ead84b. Commit 0c24e061196c21d5 ("mm: kmemleak: add rbtree and store physical address for objects allocated with PA") is not yet in 5.19 (but appears in 6.0). Without 0c24e061196c21d5, kmemleak still stores phys objects and non-phys objects in the same tree, and ignoring (instead of freeing) will cause insertions into the kmemleak object tree by the slab post-alloc hook to conflict with the pool object (see comment). Reports such as the following would appear on boot, and effectively disable kmemleak: | 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 Signed-off-by: Marco Elver Link: https://lore.kernel.org/all/b33b33bc-2d06-1bcd-2df7-43678962b728@online.de/ Signed-off-by: Greg Kroah-Hartman --- mm/kfence/core.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) --- a/mm/kfence/core.c +++ b/mm/kfence/core.c @@ -603,6 +603,14 @@ static unsigned long kfence_init_pool(vo addr += 2 * PAGE_SIZE; } + /* + * The pool is live and will never be deallocated from this point on. + * Remove the pool object from the kmemleak 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_free(__kfence_pool); + return 0; } @@ -615,16 +623,8 @@ static bool __init kfence_init_pool_earl addr = kfence_init_pool(); - 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. - */ - kmemleak_ignore_phys(__pa(__kfence_pool)); + if (!addr) return true; - } /* * Only release unprotected pages, and do not try to go back and change Patches currently in stable-queue which might be from elver@google.com are queue-5.19/revert-mm-kfence-apply-kmemleak_ignore_phys-on-early-allocated-pool.patch