Re: npf lock issue?

[Anthony Mallet <tho%netbsd.org@localhost>]

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.