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 B4FF9C433F5 for ; Tue, 12 Apr 2022 17:56:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 268406B0072; Tue, 12 Apr 2022 13:56:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2178E6B0073; Tue, 12 Apr 2022 13:56:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0E16A6B0074; Tue, 12 Apr 2022 13:56:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0120.hostedemail.com [216.40.44.120]) by kanga.kvack.org (Postfix) with ESMTP id DC6886B0072 for ; Tue, 12 Apr 2022 13:56:30 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 798AE183AB0BD for ; Tue, 12 Apr 2022 17:56:30 +0000 (UTC) X-FDA: 79348981740.30.82DDBE3 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf24.hostedemail.com (Postfix) with ESMTP id DF880180002 for ; Tue, 12 Apr 2022 17:56:29 +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 dfw.source.kernel.org (Postfix) with ESMTPS id 0D84161AB3; Tue, 12 Apr 2022 17:56:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1EAE2C385A1; Tue, 12 Apr 2022 17:56:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1649786188; bh=6oXyr4qSszqrDDIC74ST89Ik9P/w7VoRTbzZBuF4jtE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Mwyz5Grs9bx03m0WIXTHSUbER+tsU3Db4ke2pTBkBtdtNOQHEvJE5j2JrZ6hTdSS7 cLHyJlxIrfuFqRmHAN+WDkglsl2GqY+WRoihNWgeEmONNQaDPGo0Oz40wNSweoeszO H3sX0HqZidwdlHMnFwryXNEjB+jca0mRkmDH4QhRiV5v/HhuXWD2mKDll6Nf6CQnJg HannvPl5Vj9rasJCcJaWAKN91UKotJUQMWg8BjCT1SjyQs8sZCkMBTGYRFCeyySWJA O/7ok8P7fjN8sHCNoFQYVBS7eacPe1ifMm/iycXaGPGR3RGLlfAmpCY+IduPHJdpnQ MrIqLI8dDhyeA== Date: Tue, 12 Apr 2022 20:56:19 +0300 From: Mike Rapoport To: Michael Ellerman Cc: Christophe Leroy , Ariel Marcovitch , Catalin Marinas , "akpm@linux-foundation.org" , "benh@kernel.crashing.org" , "paulus@samba.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" Subject: Re: False positive kmemleak report for dtb properties names on powerpc Message-ID: References: <9dd08bb5-f39e-53d8-f88d-bec598a08c93@gmail.com> <2603cae9-3b75-cd13-1d41-2f1bed6ca32e@gmail.com> <87pmlm6bn0.fsf@mpe.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <87pmlm6bn0.fsf@mpe.ellerman.id.au> Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Mwyz5Grs; spf=pass (imf24.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Stat-Signature: 5ogb4fmpyybbbctwi9okc7grytepq7og X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: DF880180002 X-HE-Tag: 1649786189-355383 Content-Transfer-Encoding: quoted-printable 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, Apr 12, 2022 at 04:47:47PM +1000, Michael Ellerman wrote: > Christophe Leroy writes: > > Hi Ariel > > > > Le 09/04/2022 =E0 15:47, Ariel Marcovitch a =E9crit=A0: > >> Hi Christophe, did you get the chance to look at this? > > > > I tested something this morning, it works for me, see below > > > >>=20 > >> On 23/03/2022 21:06, Mike Rapoport wrote: > >>> Hi Catalin, > >>> > >>> On Wed, Mar 23, 2022 at 05:22:38PM +0000, Catalin Marinas wrote: > >>>> Hi Ariel, > >>>> > >>>> On Fri, Feb 18, 2022 at 09:45:51PM +0200, Ariel Marcovitch wrote: > >>>>> I was running a powerpc 32bit kernel (built using > >>>>> qemu_ppc_mpc8544ds_defconfig > >>>>> buildroot config, with enabling DEBUGFS+KMEMLEAK+HIGHMEM in the k= ernel > >>>>> config) > > > > ... > > > >>>>> I don't suppose I can just shuffle the calls in setup_arch() arou= nd,=20 > >>>>> so I > >>>>> wanted to hear your opinions first > >>>> I think it's better if we change the logic than shuffling the call= s. > >>>> IIUC MEMBLOCK_ALLOC_ACCESSIBLE means that __va() works on the phys > >>>> address return by memblock, so something like below (untested): > >>> MEMBLOCK_ALLOC_ACCESSIBLE means "anywhere", see commit e63075a3c937 > >>> ("memblock: Introduce default allocation limit and use it to replac= e > >>> explicit ones"), so it won't help to detect high memory. > >>> > >>> If I remember correctly, ppc initializes memblock *very* early, so=20 > >>> setting > >>> max_low_pfn along with lowmem_end_addr in > >>> arch/powerpc/mm/init_32::MMU_init() makes sense to me. > >>> > >>> Maybe ppc folks have other ideas... > >>> I've added Christophe who works on ppc32 these days. > > > > I think memblock is already available at the end of MMU_init() on PPC= 32=20 > > and at the end of early_setup() on PPC64. It means it is ready when w= e=20 > > enter setup_arch(). > > > > I tested the change below, it works for me, I don't get any kmemleak=20 > > report anymore. > > > > diff --git a/arch/powerpc/kernel/setup-common.c=20 > > b/arch/powerpc/kernel/setup-common.c > > index 518ae5aa9410..9f4e50b176c9 100644 > > --- a/arch/powerpc/kernel/setup-common.c > > +++ b/arch/powerpc/kernel/setup-common.c > > @@ -840,6 +840,9 @@ void __init setup_arch(char **cmdline_p) > > /* Set a half-reasonable default so udelay does something sensible= */ > > loops_per_jiffy =3D 500000000 / HZ; > > > > + /* Parse memory topology */ > > + mem_topology_setup(); > > + > > /* Unflatten the device-tree passed by prom_init or kexec */ > > unflatten_device_tree(); >=20 > The 64-bit/NUMA version of mem_topology_setup() requires the device tre= e > to be unflattened, so I don't think that can work. >=20 > Setting max_low_pfn etc in MMU_init() as Mike suggested seems more > likely to work. >=20 > But we might need to set it again in mem_topology_setup() though, so > that things that change memblock_end_of_DRAM() are reflected, eg. memor= y > limit or crash dump? I don't think this can cause issues for kmemleak Ariel reported. The kmemleak checks if there is a linear mapping for a PFN or that PFN is onl= y accessible via HIGHMEM. Memory limit or crash dump won't change the split= , or am I missing something? =20 > cheers --=20 Sincerely yours, Mike.