port-powerpc/55325: oea/pmap: inconsistency in usage of two PVO pools

[rokuyama.rk%gmail.com@localhost]

>Number:         55325
>Category:       port-powerpc
>Synopsis:       oea/pmap: inconsistency in usage of two PVO pools
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    port-powerpc-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun May 31 11:25:00 +0000 2020
>Originator:     Rin Okuyama
>Release:        9.99.64
>Organization:
Department of Physics, Meiji University
>Environment:
NetBSD macmini 9.99.64 NetBSD 9.99.64 (GENERIC) #65: Sun May 31 01:11:41 JST 2020  rin@latipes:/usr/src/sys/arch/macppc/compile/GENERIC macppc
>Description:
In powerpc/oea/pmap.c, there are two pools of PVO:
- pmap_upvo_pool for PVO entries for unmanaged pages
- pmap_mpvo_pool for PVO entries for managed pages

At the moment, we determine to which pool freed PVO is put back by
PVO_MANAGED flag. However, this is *wrong* when PVO is obtained by
pmap_pvo_reclaim(). That is, PVO for unmanaged pages can be reclaimed
from pool for managed, and vice versa.
>How-To-Repeat:
Enable DIAGNOSTIC, and put a system in heavy memory pressure, like

$ cd /usr/pkgsrc/devel/gcc10 && make MAKE_JOBS=2

Then, the system crashes for a while as:

panic: pr_phinpage_check: [pmap_upvopl] item 0xf619c0 poolid 36 != 1
>Fix:
Although I'm not sure whether this is a correct fix or not, but this
patch seems to fix a problem:

http://www.netbsd.org/~rin/oea_pmap_20200531.patch

Here, I introduced a new flag that represents from which pool PVO is
obtained:

#define PVO_POOL_MANAGED        0x0080
#define PVO_POOL_MANAGED_P(pvo) ((pvo)->pvo_vaddr & PVO_POOL_MANAGED)

Then, use this flag instead of PVO_MANAGED to determine to which pool
we should pool_put(9) into.

Alternatively, we can reclaim PVO from the same pool in
pmap_pvo_reclaim(). However, this attempt fails for me, by ended up in:

panic: pmap_pvo_enter: failed