Re: npf lock issue?

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Anthony Mallet <tho%netbsd.org@localhost wrote:
> | Trying to upgrade from 7.99.44 to today's -current, I have a panic
> | right away when starting npf. The boot with npf disabled is fine (see
> | note below), then when manually running `npfctl reload` the machine
> | reboots right aways with absolutely no diagnostic. This is an issue
> | that I experiencing consistently since something like last January or
> | so.
> 
> I got a useful backtrace, it's actually failing in sljit:
> 
> #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.

Alex -- do you want to have a look into this?

-- 
Mindaugas