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 84549C433EF for ; Wed, 20 Oct 2021 08:18:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 676806103B for ; Wed, 20 Oct 2021 08:18:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229823AbhJTIVH (ORCPT ); Wed, 20 Oct 2021 04:21:07 -0400 Received: from mail.kernel.org ([198.145.29.99]:38116 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229503AbhJTIVF (ORCPT ); Wed, 20 Oct 2021 04:21:05 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 504C060FD9; Wed, 20 Oct 2021 08:18:50 +0000 (UTC) Date: Wed, 20 Oct 2021 09:18:46 +0100 From: Catalin Marinas To: Mike Rapoport 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: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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. -- Catalin