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?
