On Friday 21 Apr 2017, at 22:15, Mindaugas Rasiukevicius wrote: | > #11 0xffffffff804b3075 in panic ( | > fmt=fmt@entry=0xffffffff806b6790 "uvm_km_check_empty: va %p | > has pa 0x%llx") at /usr/src/sys/kern/subr_prf.c:258 | > #12 0xffffffff8044ed05 in uvm_km_check_empty ( | > map=map@entry=0xffffffff8081c780 <module_map_store>, | > start=<optimized out>, end=18446744071572586496) at | > /usr/src/sys/uvm/uvm_km.c:563 | > #13 0xffffffff8045268f in uvm_map ( | > map=map@entry=0xffffffff8081c780 <module_map_store>, | > startp=startp@entry=0xfffffe80cc383918, size=size@entry=65536, | > uobj=<optimized out>, uoffset=uoffset@entry=-1, | > align=<optimized out>, flags=<optimized out>, | > flags@entry=5927) at /usr/src/sys/uvm/uvm_map.c:1096 | > #14 0xffffffff8044ee4f in uvm_km_alloc ( | > map=0xffffffff8081c780 <module_map_store>, | > size=size@entry=65536, align=align@entry=4096, | > flags=flags@entry=49) at /usr/src/sys/uvm/uvm_km.c:621 | > #15 0xffffffff80240a4d in alloc_chunk (size=65536) | > at | > /usr/src/sys/external/bsd/sljit/dist/sljit_src/sljitExecAllocator.c:110 | > #16 sljit_malloc_exec (size=<optimized out>) | > at | > /usr/src/sys/external/bsd/sljit/dist/sljit_src/sljitExecAllocator.c:221 | > 221 header = (struct block_header*)alloc_chunk(chunk_size); | > | > Does this ring a bell to anyone? | | This looks like a bug in sljit rather than NPF per se. The panic | message suggests some kind of KVA leak. I suspect it might be a | result of e.g. a free_chunk() call with an incorrect size in the | sljitExecAllocator.c code.
Yes. npf does not seem to be involed at all. I kept the same message subject for consistency but I guess a new thread should be started. Actually, sljit does not seem involed either. After my post, I noticed that anything that tries to uvm_km_alloc() from module_map has the same failure. On the failing machine, options MODULAR is used but I have no modules. So npf happens to be the first piece of code allocating memory from module_map (sljit actually). But, for instance, a modload(1) right after boot also fails in exactly the same way. The page that uvm_km_check_empty() finds already mapped is the very first one of module_map. I checked the latest commits in uvm since January without noticing anything suspect (and I don't have UVM_HOTPLUG defined either). But my knowledge of uvm is nearly zero ... so I did not really progress on this.