linux-kernel - Re: [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2a1592ad-bc9d-4664-fd19-f7448a37edc0@huawei.com>
Date:   Fri, 23 Apr 2021 16:11:16 +0800
From:   Kefeng Wang <wangkefeng.wang@...wei.com>
To:     Mike Rapoport <rppt@...nel.org>
CC:     <linux-arm-kernel@...ts.infradead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Anshuman Khandual <anshuman.khandual@....com>,
        Ard Biesheuvel <ardb@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        David Hildenbrand <david@...hat.com>,
        Marc Zyngier <maz@...nel.org>,
        "Mark Rutland" <mark.rutland@....com>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        "Will Deacon" <will@...nel.org>, <kvmarm@...ts.cs.columbia.edu>,
        <linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>
Subject: Re: [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify
 pfn_valid()


On 2021/4/22 23:28, Kefeng Wang wrote:
>
> On 2021/4/22 15:29, Mike Rapoport wrote:
>> On Thu, Apr 22, 2021 at 03:00:20PM +0800, Kefeng Wang wrote:
>>> On 2021/4/21 14:51, Mike Rapoport wrote:
>>>> From: Mike Rapoport <rppt@...ux.ibm.com>
>>>>
>>>> Hi,
>>>>
>>>> These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially 
>>>> hardwire
>>>> pfn_valid_within() to 1.
>>>>
>>>> The idea is to mark NOMAP pages as reserved in the memory map and 
>>>> restore
>>>> the intended semantics of pfn_valid() to designate availability of 
>>>> struct
>>>> page for a pfn.
>>>>
>>>> With this the core mm will be able to cope with the fact that it 
>>>> cannot use
>>>> NOMAP pages and the holes created by NOMAP ranges within MAX_ORDER 
>>>> blocks
>>>> will be treated correctly even without the need for pfn_valid_within.
>>>>
>>>> The patches are only boot tested on qemu-system-aarch64 so I'd really
>>>> appreciate memory stress tests on real hardware.
>>>>
>>>> If this actually works we'll be one step closer to drop custom 
>>>> pfn_valid()
>>>> on arm64 altogether.
...
>
> Ok, thanks, we met a same panic like the link on arm32(without 
> HOLES_IN_ZONE),
>
> the scheme for arm64 could be suit for arm32, right?  I will try the 
> patchset with
>
> some changes on arm32 and give some feedback.

I tested this patchset(plus arm32 change, like arm64 does) based on lts 
5.10，add

some debug log, the useful info shows below, if we enable HOLES_IN_ZONE, 
no panic,

any idea, thanks.

Zone ranges:
   Normal   [mem 0x0000000080a00000-0x00000000b01fffff]
   HighMem  [mem 0x00000000b0200000-0x00000000ffffefff]
Movable zone start for each node
Early memory node ranges
   node   0: [mem 0x0000000080a00000-0x00000000855fffff]
   node   0: [mem 0x0000000086a00000-0x0000000087dfffff]
   node   0: [mem 0x000000008bd00000-0x000000008c4fffff]
   node   0: [mem 0x000000008e300000-0x000000008ecfffff]
   node   0: [mem 0x0000000090d00000-0x00000000bfffffff]
   node   0: [mem 0x00000000cc000000-0x00000000dc9fffff]
   node   0: [mem 0x00000000de700000-0x00000000de9fffff]
   node   0: [mem 0x00000000e0800000-0x00000000e0bfffff]
   node   0: [mem 0x00000000f4b00000-0x00000000f6ffffff]
   node   0: [mem 0x00000000fda00000-0x00000000ffffefff]

----> free_memmap, start_pfn = 85800,  85800000 end_pfn = 86a00, 86a00000
----> free_memmap, start_pfn = 8c800,  8c800000 end_pfn = 8e300, 8e300000
----> free_memmap, start_pfn = 8f000,  8f000000 end_pfn = 90000, 90000000
----> free_memmap, start_pfn = dcc00,  dcc00000 end_pfn = de700, de700000
----> free_memmap, start_pfn = dec00,  dec00000 end_pfn = e0000, e0000000
----> free_memmap, start_pfn = e0c00,  e0c00000 end_pfn = e4000, e4000000
----> free_memmap, start_pfn = f7000,  f7000000 end_pfn = f8000, f8000000
=== >move_freepages: start_pfn/end_pfn [de600, de7ff], [de600000, 
de7ff000] :  pfn =de600 pfn2phy = de600000 , page = ef3cc000, page-flags 
= ffffffff
8<--- cut here ---
Unable to handle kernel paging request at virtual address fffffffe
pgd = 5dd50df5
[fffffffe] *pgd=affff861, *pte=00000000, *ppte=00000000
Internal error: Oops: 37 [#1] SMP ARM
Modules linked in: gmac(O)
CPU: 2 PID: 635 Comm: test-oom Tainted: G           O      5.10.0+ #31
Hardware name: Hisilicon A9
PC is at move_freepages_block+0x150/0x278
LR is at move_freepages_block+0x150/0x278
pc : [<c02383a4>]    lr : [<c02383a4>]    psr: 200e0393
sp : c4179cf8  ip : 00000000  fp : 00000001
r10: c4179d58  r9 : 000de7ff  r8 : 00000000
r7 : c0863280  r6 : 000de600  r5 : 000de600  r4 : ef3cc000
r3 : ffffffff  r2 : 00000000  r1 : ef5d069c  r0 : fffffffe
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 1ac5387d  Table: 83b0c04a  DAC: 55555555
Process test-oom (pid: 635, stack limit = 0x25d667df)