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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8A84BC433ED for ; Fri, 7 May 2021 10:30:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2C10161460 for ; Fri, 7 May 2021 10:30:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2C10161460 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 924FD8D000A; Fri, 7 May 2021 06:30:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8C1798D0006; Fri, 7 May 2021 06:30:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 728558D000A; Fri, 7 May 2021 06:30:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0028.hostedemail.com [216.40.44.28]) by kanga.kvack.org (Postfix) with ESMTP id 53A358D0006 for ; Fri, 7 May 2021 06:30:45 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 179C282499A8 for ; Fri, 7 May 2021 10:30:45 +0000 (UTC) X-FDA: 78114066450.22.7ADBD36 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf08.hostedemail.com (Postfix) with ESMTP id 5B0D180192E7 for ; Fri, 7 May 2021 10:30:19 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 17B75613F0; Fri, 7 May 2021 10:30:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1620383443; bh=xO2yiNtWQ2O7eOAXqEu52tCA2HTisM05D8ogUeVRGIs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=I3wci5mv4Gs6EyRYz2OZSjpzVQI/OLGQ7wJFnSwJzXhSaAZezyd872uqmd8eixDl2 rFFe4IKS7TI1CU69Ujl5e9Qak2z6h7yGx0BJacxyzPTLMnHFOeTfrCTAQvPgGxOZ/3 2MtQGiRFNnfqAjpay08cGhYotePU1XN36qEKlKPqQiNZgDVPcYRIJ4wOJDDZ8SjD0V QMcmkJr6dqXSPBgebph8z/PdGUnNKfZLKvG7sVr944ubJVoyhTk2YEQxv5vRYHKsAo 75YjeuioJyCebAUNHpVf0f6O6/x/FqVOx5f1rf+PIOFaZadL9MsZadfp0YvXsJPFf3 0t9HnWVV6NieA== Date: Fri, 7 May 2021 13:30:35 +0300 From: Mike Rapoport To: Kefeng Wang Cc: David Hildenbrand , linux-arm-kernel@lists.infradead.org, Andrew Morton , Anshuman Khandual , Ard Biesheuvel , Catalin Marinas , Marc Zyngier , Mark Rutland , Mike Rapoport , Will Deacon , kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid()) Message-ID: References: <6ad2956c-70ae-c423-ed7d-88e94c88060f@huawei.com> <0cb013e4-1157-f2fa-96ec-e69e60833f72@huawei.com> <24b37c01-fc75-d459-6e61-d67e8f0cf043@redhat.com> <82cfbb7f-dd4f-12d8-dc76-847f06172200@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=I3wci5mv; spf=pass (imf08.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-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 5B0D180192E7 X-Stat-Signature: 9aw3ze77rfcjmcp6m8p6oaj3hi8kdfwj Received-SPF: none (kernel.org>: No applicable sender policy available) receiver=imf08; identity=mailfrom; envelope-from=""; helo=mail.kernel.org; client-ip=198.145.29.99 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620383419-198612 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 Fri, May 07, 2021 at 03:17:08PM +0800, Kefeng Wang wrote: >=20 > On 2021/5/6 20:47, Kefeng Wang wrote: > >=20 > >=20 > > > > > > no, the CONFIG_ARM_LPAE is not set, and yes with same panic a= t > > > > > > move_freepages at > > > > > >=20 > > > > > > start_pfn/end_pfn [de600, de7ff], [de600000, de7ff000] > > > > > > :=C2=A0 pfn =3Dde600, page > > > > > > =3Def3cc000, page-flags =3D ffffffff,=C2=A0 pfn2phy =3D de600= 000 > > > > > >=20 > > > > > > > > __free_memory_core, range: 0xb0200000 - > > > > > > > > 0xc0000000, pfn: b0200 - b0200 > > > > > > > > __free_memory_core, range: 0xcc000000 - > > > > > > > > 0xdca00000, pfn: cc000 - b0200 > > > > > > > > __free_memory_core, range: 0xde700000 - > > > > > > > > 0xdea00000, pfn: de700 - b0200 > > > > >=20 > > > > > Hmm, [de600, de7ff] is not added to the free lists which is > > > > > correct. But > > > > > then it's unclear how the page for de600 gets to move_freepages= ()... > > > > >=20 > > > > > Can't say I have any bright ideas to try here... > > > >=20 > > > > Are we missing some checks (e.g., PageReserved()) that > > > > pfn_valid_within() > > > > would have "caught" before? > > >=20 > > > Unless I'm missing something the crash happens in __rmqueue_fallbac= k(): > > >=20 > > > do_steal: > > > =C2=A0=C2=A0=C2=A0=C2=A0page =3D get_page_from_free_area(area, fall= back_mt); > > >=20 > > > =C2=A0=C2=A0=C2=A0=C2=A0steal_suitable_fallback(zone, page, alloc_f= lags, start_migratetype, > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 can_steal); > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> move_freepages() > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = -> BUG() > > >=20 > > > So a page from free area should be sane as the freed range was neve= r > > > added > > > it to the free lists. > >=20 > > Sorry for the late response due to the vacation. > >=20 > > The pfn in range [de600, de7ff] won't be added into the free lists vi= a > > __free_memory_core(), but the pfn could be added into freelists via > > free_highmem_page() > >=20 > > I add some debug[1] in add_to_free_list(), we could see the calltrace > >=20 > > free_highpages, range_pfn [b0200, c0000], range_addr [b0200000, c0000= 000] > > free_highpages, range_pfn [cc000, dca00], range_addr [cc000000, dca00= 000] > > free_highpages, range_pfn [de700, dea00], range_addr [de700000, dea00= 000] > > add_to_free_list, =3D=3D=3D> pfn =3D de700 > > ------------[ cut here ]------------ > > WARNING: CPU: 0 PID: 0 at mm/page_alloc.c:900 add_to_free_list+0x8c/0= xec > > pfn =3D de700 > > Modules linked in: > > CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0+ #48 > > Hardware name: Hisilicon A9 > > [] (show_stack) from [] (dump_stack+0x9c/0xc0) > > [] (dump_stack) from [] (__warn+0xc0/0xec) > > [] (__warn) from [] (warn_slowpath_fmt+0x74/0xa4) > > [] (warn_slowpath_fmt) from [] > > (add_to_free_list+0x8c/0xec) > > [] (add_to_free_list) from [] > > (free_pcppages_bulk+0x200/0x278) > > [] (free_pcppages_bulk) from [] > > (free_unref_page+0x58/0x68) > > [] (free_unref_page) from [] > > (free_highmem_page+0xc/0x50) > > [] (free_highmem_page) from [] (mem_init+0x21c/0x= 254) > > [] (mem_init) from [] (start_kernel+0x258/0x5c0) > > [] (start_kernel) from [<00000000>] (0x0) > >=20 > > so any idea? >=20 > If pfn =3D 0xde700, due to the pageblock_nr_pages =3D 0x200, then the > start_pfn,end_pfn passed to move_freepages() will be [de600, de7ff], > but the range of [de600,de700] without =E2=80=98struct page' will lead = to > this panic when pfn_valid_within not enabled if no HOLES_IN_ZONE, > and the same issue will occurred in isolate_freepages_block(), maybe I think your analysis is correct except one minor detail. With the #ifdef fix I've proposed earlieri [1] the memmap for [0xde600, 0xde700] should n= ot be freed so there should be a struct page. Did you check what parts of th= e memmap are actually freed with this patch applied? Would you get a panic if you add dump_page(pfn_to_page(0xde600), ""); say, in the end of memblock_free_all()? > there are some scene, so I select HOLES_IN_ZONE in ARCH_HISI(ARM) to so= lve > this issue in our 5.10, should we select HOLES_IN_ZONE in all ARM or on= ly in > ARCH_HISI, any better solution? Thanks. I don't think that HOLES_IN_ZONE is the right solution. I believe that we must keep the memory map aligned on pageblock boundaries. That's surely n= ot the case for SPARSEMEM as of now, and if my fix is not enough we need to find where it went wrong. Besides, I'd say that if it is possible to update your firmware to make t= he memory layout reported to the kernel less, hmm, esoteric, you would hit less corner cases. [1] https://lore.kernel.org/lkml/YIpY8TXCSc7Lfa2Z@kernel.org --=20 Sincerely yours, Mike.