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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 60B96C433F5 for ; Wed, 20 Oct 2021 08:42:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 07890611EF for ; Wed, 20 Oct 2021 08:42:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 07890611EF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 7C46D6B0071; Wed, 20 Oct 2021 04:42:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7743D6B0072; Wed, 20 Oct 2021 04:42:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 663336B0073; Wed, 20 Oct 2021 04:42:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0149.hostedemail.com [216.40.44.149]) by kanga.kvack.org (Postfix) with ESMTP id 56E5E6B0071 for ; Wed, 20 Oct 2021 04:42:36 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 09EFF180AD820 for ; Wed, 20 Oct 2021 08:42:36 +0000 (UTC) X-FDA: 78716174712.08.923211F Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf09.hostedemail.com (Postfix) with ESMTP id AD7D63000105 for ; Wed, 20 Oct 2021 08:42:33 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 9A83A61004; Wed, 20 Oct 2021 08:42:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1634719354; bh=MHBvccfg0JwTU+CXuSh0R6J6oYNHZE8t6dgpeztT6ac=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LFZW0NNmwO3pGqS9Aj8Lr9v1SepIjAQQ4SoZ0vSRlepepkzuAiH0qRQeGu6xP/tdl hiSUgcO5+mOqF1wvgyPIH7rtaXPdMygvwvtcsxhwaPCriOC83uOjEw76mwGJvPADwu 4XfWUZ5zq70jVYnlOCnRwhnS3dlLJG1fAnQE9aLqYBJJ0QygG5/7QT/16gq8CAGj6w aUpfacbzDhd2jMGJGj3QmczB8daadDRUA8MvB2/8CQBv60QaMYEVaWmNU3jZfcQJu8 dsalOTLgMjaNNdIssNHihAO7nZMccwUMQL62GH9VOgT4xVAb0spRKMeVvBmxRoRcci ofZgvHRSgsFdw== Date: Wed, 20 Oct 2021 11:42:28 +0300 From: Mike Rapoport To: Catalin Marinas Cc: Qian Cai , linux-mm@kvack.org, Andrew Morton , Mike Rapoport , Vladimir Zapolskiy , linux-kernel@vger.kernel.org, Linus Torvalds Subject: Re: [PATCH] memblock: exclude NOMAP regions from kmemleak Message-ID: References: <20211013054756.12177-1-rppt@kernel.org> <089478ad-3755-b085-d9aa-c68e9792895c@quicinc.com> <8da41896-dc11-8246-54cf-1174f617ac39@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: zi6148jwzacqg678ua63uc7drb394pn3 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: AD7D63000105 Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=LFZW0NNm; spf=pass (imf09.hostedemail.com: domain of rppt@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-HE-Tag: 1634719353-972622 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 Wed, Oct 20, 2021 at 09:18:46AM +0100, Catalin Marinas wrote: > On Wed, Oct 20, 2021 at 10:38:23AM +0300, Mike Rapoport wrote: > > On Tue, Oct 19, 2021 at 09:33:11PM +0300, Mike Rapoport wrote: > > > On Tue, Oct 19, 2021 at 01:59:22PM -0400, Qian Cai wrote: > > > > [ 0.000000][ T0] Booting Linux on physical CPU 0x0000000000 [0x503f0002] > > > > [ 0.000000][ T0] Linux version 5.15.0-rc6-next-20211019+ (root@admin5) (gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #104 SMP Tue Oct 19 17:36:17 UTC 2021 > > > > [ 0.000000][ T0] earlycon: pl11 at MMIO32 0x0000000012600000 (options '') > > > > [ 0.000000][ T0] printk: bootconsole [pl11] enabled > > > > [ 0.000000][ T0] efi: Getting UEFI parameters from /chosen in DT: > > > > [ 0.000000][ T0] efi: System Table : 0x0000009ff7de0018 > > > > [ 0.000000][ T0] efi: MemMap Address : 0x0000009fe6dae018 > > > > [ 0.000000][ T0] efi: MemMap Size : 0x0000000000000600 > > > > [ 0.000000][ T0] efi: MemMap Desc. Size : 0x0000000000000030 > > > > [ 0.000000][ T0] efi: MemMap Desc. Version : 0x0000000000000001 > > > > [ 0.000000][ T0] efi: EFI v2.70 by American Megatrends > > > > [ 0.000000][ T0] efi: ACPI 2.0=0x9ff5b40000 SMBIOS 3.0=0x9ff686fd98 ESRT=0x9ff1d18298 MEMRESERVE=0x9fe6dacd98 > > > > [ 0.000000][ T0] efi: Processing EFI memory map: > > > > [ 0.000000][ T0] efi: 0x000090000000-0x000091ffffff [Conventional| | | | | | | | | | |WB|WT|WC|UC] > > > > [ 0.000000][ T0] efi: 0x000092000000-0x0000928fffff [Runtime Data|RUN| | | | | | | | | |WB|WT|WC|UC] > > > > [ 0.000000][ T0] ------------[ cut here ]------------ > > > > [ 0.000000][ T0] kernel BUG at mm/kmemleak.c:1140! > > > > [ 0.000000][ T0] Internal error: Oops - BUG: 0 [#1] SMP > > > > > > > > I did not quite figure out where this BUG() was triggered and I did not > > > > > > This is from here: > > > arch/arm64/include/asm/memory.h: > > > > > > #define PHYS_OFFSET ({ VM_BUG_ON(memstart_addr & 1); memstart_addr; }) > > > > > > kmemleak_free_part_phys() does __va() which uses PHYS_OFFSET and all this > > > happens before memstart_addr is set. > > > > > > I'll try to see how this can be untangled... > > > > This late in the cycle I can only think of reverting kmemleak wavier from > > memblock_mark_nomap() and putting it in > > early_init_dt_alloc_reserved_memory_arch() being the only user setting > > MEMBLOCK_NOMAP to an allocated chunk rather than marking NOMAP "unusable" > > memory reported by firmware. > > It makes sense, there aren't many places or nomap is called. > > I think arch_reserve_mem_area() called from acpi_table_upgrade() also > follows a memblock allocation. But I'd call kmemleak in > acpi_table_upgrade() directly rather than in the arch back-end. Hmm, not sure this is correct for x86. I don't see why can't it track the memory allocated in acpi_table_upgrade(). > Regarding which callback, I think kmemleak_ignore_phys() is better > suited here since kmemleak still keeps track of the object but won't > scan it. Ok. -- Sincerely yours, Mike.