Re: UVMHIST, pmap_get_physpage panic

[Maxime Villard <max%m00nbsd.net@localhost>]

Le 17/12/2018 à 08:10, Thomas Klausner a écrit :
> On Mon, Dec 17, 2018 at 08:06:36AM +0100, Maxime Villard wrote:
> > Le 16/12/2018 à 09:09, Thomas Klausner a écrit :
> > > [ 16674.534547] panic: pmap_get_physpage: out of memory
> >
> > Well, out of memory means out of memory. KASAN consumes a bit more than
> > 1/8 of the KVA. So if in normal times your system would use 8GB of ram,
> > KASAN adds an extra ~1.1GB.
>
> So why doesn't it kill userland processes? I don't believe my kernel
> needs all 32GB of RAM.

I don't know. In fact I don't understand how it is normal to get this:

[ 16674.544550] pmap_growkernel() at netbsd:pmap_growkernel
[ 16674.544550] kasan_shadow_map() at netbsd:kasan_shadow_map+0xff
[ 16674.544550] pmap_growkernel() at netbsd:pmap_growkernel+0x283

pmap_growkernel() does

	mutex_enter(kpm->pm_lock);

So if it's called recursively I think we have a problem. The call
path is:

	pmap_growkernel -> kasan_shadow_map -> pmap_get_physpage ->
	    [somewhere we need to allocate KVA] -> pmap_growkernel

This problem is not KASAN-specific, because KASAN just duplicates
the existing logic:

	pmap_growkernel -> pmap_alloc_level -> pmap_get_physpage

Maybe KASAN makes the problem more visible.

Do you also get out-of-memory when you disable UVMHIST?