On Tue, Mar 2, 2021 at 10:56 AM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, Mar 1, 2021 at 11:59 PM Ilya Lipnitskiy > <ilya.lipnitskiy@xxxxxxxxx> wrote: > > > > Good to know. Some more digging and I can say that we hit this error > > when trying to unmap PFN 0 (is_zero_pfn(pfn) returns TRUE, > > vm_normal_page returns NULL, zap_pte_range does not decrement > > MM_ANONPAGES RSS counter). Is my understanding correct that PFN 0 is > > usable, but special? Or am I totally off the mark here? > > PFN 0 should be usable - depending on architecture, of course - and > shouldn't even be special in any way. > > is_zero_pfn(pfn) is *not* meant to test for pfn being 0 - it's meant > to test for the pfn pointing to the special zero-filled page. The two > _could_ be the same thing, of course, but generally are not (h8300 > seems to say "we use pfn 0 as the zero page" if I read things right). > > In fact, there can be many zero-filled pages - architectures with > virtually mapped caches that want cache coloring have multiple > contiguous zero-filled pages and then map in the right one based on > virtual address. I'm not sure why it would matter (the zero-page is > always mapped read-only, so any physical aliases should be a > non-issue), but whatever.. > > > Here is the (optimized) stack trace when the counter does not get decremented: > > [<8015b078>] vm_normal_page+0x114/0x1a8 > > Yes, if "is_zero_pfn()" returns true, then it won't be considered a > normal page, and is not refcounted. > > But that should only trigger for pfn == zero_pfn, and zero_pfn should > be initialized to > > zero_pfn = page_to_pfn(ZERO_PAGE(0)); > > so it _sounds_ like you possibly have something odd going on with ZERO_PAGE. Thanks for explaining this - I have figured out that zero_pfn gets set a little late (see other response for details). Until init_zero_pfn() is called, zero_pfn==0, after - zero_pfn==5120. Seems somewhat bad, unless my system is breaking rules by checking zero_pfn before it was initialized ;) > > Yes, one architecture does actually make pfn 0 _be_ the zero page, but > you said MIPS, and that does do the page coloring games, and has > > #define ZERO_PAGE(vaddr) \ > (virt_to_page((void *)(empty_zero_page + (((unsigned > long)(vaddr)) & zero_page_mask)))) > > where zero_page_mask is the page colorign mask, and empty_zero_page is > allocated in setup_zero_pages() fairly early in mem_init() (again, it > allocates multiple pages depending on the page ordering - see that > horrible virtual cache thing with cpu_has_vce). > > So PFN 0 shouldn't be an issue at all. > > Of course, since you said this was an embedded MIPS platform, maybe > it's one of the broken ones with virtual caches and cpu_has_vce is > set. I'm not sure how much testing that has gotten lately. MOST of the > later MIPS architectures walked away from the pure virtual cache > setups. FWIW, here is the CPU info from my platform, and cpu_has_vce is not set: system type : MediaTek MT7621 ver:1 eco:3 machine : Ubiquiti EdgeRouter X processor : 0 cpu model : MIPS 1004Kc V2.15 BogoMIPS : 581.63 wait instruction : yes microsecond timers : yes tlb_entries : 32 extra interrupt vector : yes hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb] isa : mips1 mips2 mips32r1 mips32r2 ASEs implemented : mips16 dsp mt Options implemented : tlb 4kex 4k_cache prefetch mcheck ejtag llsc pindexed_dcache userlocal vint perf_cntr_intr_bit cdmm perf shadow register sets : 1 kscratch registers : 0 package : 0 core : 0 VPE : 0 VCED exceptions : not available VCEI exceptions : not available > > Linus Ilya