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 13D7CC25B0E for ; Tue, 16 Aug 2022 16:43:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 73E6E8D0001; Tue, 16 Aug 2022 12:43:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6ECBF6B0075; Tue, 16 Aug 2022 12:43:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5B4988D0001; Tue, 16 Aug 2022 12:43:24 -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 4BC206B0073 for ; Tue, 16 Aug 2022 12:43:24 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 1514BA096D for ; Tue, 16 Aug 2022 16:43:24 +0000 (UTC) X-FDA: 79806026328.02.6272CB5 Received: from mail-yw1-f175.google.com (mail-yw1-f175.google.com [209.85.128.175]) by imf17.hostedemail.com (Postfix) with ESMTP id BAB94401C0 for ; Tue, 16 Aug 2022 16:43:23 +0000 (UTC) Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-3246910dac3so166071377b3.12 for ; Tue, 16 Aug 2022 09:43:23 -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=FOpQGOCCCOeHXcTTEf2Jf8cH6crBmZD9kljFNdM3FZI=; b=MTj13ZQOudsv0Y/McakJDk6R1ExbHgwbtUeK89PeymxtSWo3zoC/Q+XY5F0T9OgxhA CzABOs9R7GE90wClbCdVOrcM6GRfOKwq+0a/5wfHvjtt6DYvaF1PRFQQ3M062sfAtwI4 8UnQAo38spsmsPCYWMBFEbqgijBH+I/eJMfioC6BVTs7FJi2en4QOqZKHDlWzdImDdH+ J6IVV754BSXjX/oT6ElqiIjwORuzURt2RgAmqdA3R9RHomDzCMQf2wRPzE28XTQv2ajt bB05KJTL9nz58MGwokLqh0fOH7HYqUj+tJgv4ZQMpboYpqVIKxfZcJykgQQFCFG6VrxU vPoA== 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=FOpQGOCCCOeHXcTTEf2Jf8cH6crBmZD9kljFNdM3FZI=; b=VEYeZyC1sffO9cu2AkAOCV4napg8OaYW+2U6FhxmFNVwPglailtFlVmLjnV7eoZqQM WSMvCGA75xusYvOp3E1o/Sm81Y2xRJG06z4lcORcH/gNV5drOlfN2gX5m4pQz4kIvNtJ EguTuwt9GC9SDRUB5CQk5A5lYQtg2T6e5Jh84CC4lD2OAIJIz0+NRoewpuRhv/kaeqaL kwxWy63o30P3iwMXotuh7kxAEZFB6QZqN6NI0waBBrTmMxIKBX2GfObrUdlVLsKndAmJ VxIJ8x+ph10C69V4t2J1hf3A99Jl8BcRlT03NXkg4x8IopYA8bJAGA26/r7dYy3n6Sk8 UN5g== X-Gm-Message-State: ACgBeo35z2Lt843XoG1M8bQjqZdZl6MUyGfs4y9X9es4ailJJSQqZiih 90WqjCrYcqNs4LQsSD6/n8HXnfW6LJzvGNNk2/hzvg== X-Google-Smtp-Source: AA6agR4FvwhB43vbINiId5VrN/UidMBLEc0XDLd20dewxucrXu77Ob4LcptLKymiABwR4E47RjbNq3rfNRF4Q3GtxXE= X-Received: by 2002:a81:500a:0:b0:333:9bcd:8a41 with SMTP id e10-20020a81500a000000b003339bcd8a41mr2849801ywb.4.1660668202873; Tue, 16 Aug 2022 09:43:22 -0700 (PDT) MIME-Version: 1.0 References: <20220816163641.2359996-1-elver@google.com> In-Reply-To: <20220816163641.2359996-1-elver@google.com> From: Marco Elver Date: Tue, 16 Aug 2022 18:42:46 +0200 Message-ID: Subject: Re: [PATCH 5.19.y] 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 Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660668203; a=rsa-sha256; cv=none; b=Z+xL5Jy2YVB6aqyhtDgERwH36uOmRrTNMkgweoRtML4MugSzBdb6tSwVgHsY+2/tlJCIn5 axTL+FBbKZ/h0eIgMJHUO0L2ltQ/uS7j38nIJGCvc6ej4/98Sz4MXvYyH2mu7EQcU1rnCs L7Z/3+eMpfe+VP3QNOezSRlH4Wxpct0= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=MTj13ZQO; spf=pass (imf17.hostedemail.com: domain of elver@google.com designates 209.85.128.175 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660668203; 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=FOpQGOCCCOeHXcTTEf2Jf8cH6crBmZD9kljFNdM3FZI=; b=K2YMRwzCKwbarQ6QrdHiRCY5zr0tnI47qe7XKhqjtrZNokWoEFFOa0Ucjyym1bfAcY0uE6 IJ8RFpltsesopZYXFtLupdWcpDhb6aKw+EpOiEhppcYFQ6q4HrHfAYfJMGc8lpQLar7MXS HKUSH49NCgeDNBa3QoCPhgWjxw847uk= Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=MTj13ZQO; spf=pass (imf17.hostedemail.com: domain of elver@google.com designates 209.85.128.175 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-Stat-Signature: a6qhiot9ci8t7dp1uw5kwe86kgrtzx4z X-Rspamd-Queue-Id: BAB94401C0 X-Rspamd-Server: rspam06 X-HE-Tag: 1660668203-807343 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, 16 Aug 2022 at 18:37, Marco Elver wrote: > > 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 The discussion is: Link: https://lore.kernel.org/all/b33b33bc-2d06-1bcd-2df7-43678962b728@online.de/ > --- > mm/kfence/core.c | 18 +++++++++--------- > 1 file changed, 9 insertions(+), 9 deletions(-) > > diff --git a/mm/kfence/core.c b/mm/kfence/core.c > index 6aff49f6b79e..4b5e5a3d3a63 100644 > --- a/mm/kfence/core.c > +++ b/mm/kfence/core.c > @@ -603,6 +603,14 @@ static unsigned long kfence_init_pool(void) > 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_early(void) > > 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 > -- > 2.37.1.595.g718a3a8f04-goog >