Re: exec error: BUG: Bad rss-counter

[Ilya Lipnitskiy]

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