Re: [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid()

[Kefeng Wang]

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@xxxxxxxxxxxxx>
> > > >
> > > > 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)