Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: UVMHIST, pmap_get_physpage panic

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


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?

Home | Main Index | Thread Index | Old Index