Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp3379843pxv; Mon, 28 Jun 2021 03:21:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw12Y8/dR34bP/abLAVUsDiy5PG1QsJbMLnZ1XZfxp1TSmnu9DaCmNiKCBZsyp7/ynzo+L8 X-Received: by 2002:a92:6d0b:: with SMTP id i11mr17649339ilc.160.1624875672875; Mon, 28 Jun 2021 03:21:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624875672; cv=none; d=google.com; s=arc-20160816; b=V5OR/a//NSms5lFaUdt2KvH71vrRtKEYw7s9hfhYJz00cCLAiHbcogydejkJRFCf9+ 2cdG5OOL4sfgL2J65C/abdKxRFbxfk3bK1PUdUG2dXr2aDjiVJ9KKxjlTygSn+WOaSNX B4HyiwO0YX6jo+t6LFLidKhdE9KzuzW5r6JYDtDoae+IxB9sHckHnAvRekkGYy0ti2E5 Oav2NevDZUYh9FcZuPJkz0zFkPhWGBI3xSOwwlxpDcEXzf2vnfuVji9WOWWUVOfxK/I7 GfFvKOfr9iU2N/GoZnFMC6mMDYxePcj0GOuLtSKiljud7KByFD5+M6tTzofwEdQt7Pte oaog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=H20PImBsoeb++lBLVVSgsS2BmQL3tVZGoWUJ+o3T2yY=; b=UAKgLwYsQJ+0gCaLHDDkTR/sM665ULfdscnnXj6yty94MB8rXbQrmZ6ghIUxvYue3G pcPJGKx3fYY7Pop8eFEXHWQ1VeR+MeozxoD58zhM702+act/4KxJ1HhhX0ZhiKmHa4qz Pj7T0QnIlCLpJS5qafdYpIG0RGGHHJ3VoqXHrsl8m/PSsKUag22RBMKLDOr3lv0pJ5gv /eJf12yKLaSIN6c+gzfJycMRNsxGIiA3YCA/ufn46OnsXO+GOTtRBw+eEVXiWbxoqV2N ic1SN6BFaJC4GGqPxB6m5E1ibW6jRgVloOJEjYH/XaQ3e23X5GE6TTpukYboszmjXZit +m4w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r24si16006914iog.39.2021.06.28.03.21.00; Mon, 28 Jun 2021 03:21:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232617AbhF1KWm (ORCPT + 99 others); Mon, 28 Jun 2021 06:22:42 -0400 Received: from muru.com ([72.249.23.125]:57516 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232426AbhF1KWl (ORCPT ); Mon, 28 Jun 2021 06:22:41 -0400 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id EFAE68047; Mon, 28 Jun 2021 10:20:25 +0000 (UTC) Date: Mon, 28 Jun 2021 13:20:11 +0300 From: Tony Lindgren To: Mike Rapoport Cc: linux-arm-kernel@lists.infradead.org, Andrew Morton , Kefeng Wang , Mike Rapoport , Russell King , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-omap@vger.kernel.org, regressions@lists.linux.dev Subject: Re: [PATCH v2 3/3] arm: extend pfn_valid to take into accound freed memory map alignment Message-ID: References: <20210519141436.11961-1-rppt@kernel.org> <20210519141436.11961-4-rppt@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210519141436.11961-4-rppt@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Looks like this patch causes a boot regression at least for Cortex-A15. That's commit 990e6d0e1de8 ("arm: extend pfn_valid to take into accound freed memory map alignment") in Linux next. Most of the time I see the following on beagle-x15 right after init starts: Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b CPU0: stopping CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.13.0-rc7-next-20210625 #100 Hardware name: Generic DRA74X (Flattened Device Tree) [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack_lvl+0x40/0x4c) [] (dump_stack_lvl) from [] (do_handle_IPI+0x2c8/0x334) [] (do_handle_IPI) from [] (ipi_handler+0x14/0x20) [] (ipi_handler) from [] (handle_percpu_devid_irq+0xa8/0x22c) [] (handle_percpu_devid_irq) from [] (handle_domain_irq+0x64/0xa4) [] (handle_domain_irq) from [] (gic_handle_irq+0x88/0xb0) [] (gic_handle_irq) from [] (__irq_svc+0x6c/0x90) Exception stack(0xc0f01f08 to 0xc0f01f50) 1f00: 00000f38 00000f37 00000000 fe600000 c0ff90c0 00000000 1f20: c0f0520c c0f05260 00000000 c0f00000 00000000 c0e788f0 00000000 c0f01f58 1f40: c0126aa0 c0107dc4 60000013 ffffffff [] (__irq_svc) from [] (arch_cpu_idle+0x1c/0x3c) [] (arch_cpu_idle) from [] (default_idle_call+0x38/0xe0) [] (default_idle_call) from [] (do_idle+0x214/0x2cc) [] (do_idle) from [] (cpu_startup_entry+0x18/0x1c) [] (cpu_startup_entry) from [] (start_kernel+0x5cc/0x6c4) Sometimes the system boots to console, but maybe only about 20% of the time. Reverting 990e6d0e1de8 makes Linux next boot again for me. Regards, Tony #regzb introduced: 990e6d0e1de8 ("arm: extend pfn_valid to take into accound freed memory map alignment") * Mike Rapoport [700101 02:00]: > From: Mike Rapoport > > When unused memory map is freed the preserved part of the memory map is > extended to match pageblock boundaries because lots of core mm > functionality relies on homogeneity of the memory map within pageblock > boundaries. > > Since pfn_valid() is used to check whether there is a valid memory map > entry for a PFN, make it return true also for PFNs that have memory map > entries even if there is no actual memory populated there. > > Signed-off-by: Mike Rapoport > --- > arch/arm/mm/init.c | 13 ++++++++++++- > 1 file changed, 12 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c > index 9d4744a632c6..6162a070a410 100644 > --- a/arch/arm/mm/init.c > +++ b/arch/arm/mm/init.c > @@ -125,11 +125,22 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max_low, > int pfn_valid(unsigned long pfn) > { > phys_addr_t addr = __pfn_to_phys(pfn); > + unsigned long pageblock_size = PAGE_SIZE * pageblock_nr_pages; > > if (__phys_to_pfn(addr) != pfn) > return 0; > > - return memblock_is_map_memory(addr); > + /* > + * If address less than pageblock_size bytes away from a present > + * memory chunk there still will be a memory map entry for it > + * because we round freed memory map to the pageblock boundaries. > + */ > + if (memblock_overlaps_region(&memblock.memory, > + ALIGN_DOWN(addr, pageblock_size), > + pageblock_size)) > + return 1; > + > + return 0; > } > EXPORT_SYMBOL(pfn_valid); > #endif > -- > 2.28.0 >