Re: panic with NPF tables and debug/lockdebug on amd64

2018-10-02 Thread Geoff Wing
On Friday 2018-09-28 19:05 +1000, Geoff Wing output:
:Hi,
:I'm seeing a kassert panic with NPF tables and kernel options DEBUG/LOCKDEBUG
:
:config:
:   include "arch/amd64/conf/GENERIC"
:   options DEBUG
:   options LOCKDEBUG
:

Hi,
this is with the nv changes to npf (sources 2018-10-02 06:00 UTC).

(gdb) bt
#0  0x80222da5 in cpu_reboot (howto=howto@entry=260, 
bootstr=bootstr@entry=0x0) at /usr/netbsd/src/sys/arch/amd64/amd64/machdep.c:726
#1  0x809e1949 in vpanic (fmt=fmt@entry=0x813f4710 "LOCKDEBUG: 
%s error: %s,%zu: %s", ap=ap@entry=0xab8069c78948)
at /usr/netbsd/src/sys/kern/subr_prf.c:335
#2  0x809e19e0 in panic (fmt=fmt@entry=0x813f4710 "LOCKDEBUG: 
%s error: %s,%zu: %s") at /usr/netbsd/src/sys/kern/subr_prf.c:254
#3  0x809d82d5 in lockdebug_abort1 (func=0x81281c20 
<__func__.6114> "assert_sleepable", line=70, ld=0xab80092246b8, s=6,
msg=0x813f4556 "spin lock held", dopanic=) at 
/usr/netbsd/src/sys/kern/subr_lockdebug.c:807
#4  0x80993df2 in assert_sleepable () at 
/usr/netbsd/src/sys/kern/kern_lock.c:70
#5  0x809df98f in pool_cache_get_paddr (pc=0x896889ddb500, 
flags=flags@entry=1, pap=pap@entry=0x0) at 
/usr/netbsd/src/sys/kern/subr_pool.c:2283
#6  0x809d4ff0 in kmem_intr_alloc 
(requested_size=requested_size@entry=64, kmflags=kmflags@entry=1) at 
/usr/netbsd/src/sys/kern/subr_kmem.c:268
#7  0x809d5257 in kmem_intr_zalloc (size=size@entry=64, 
kmflags=kmflags@entry=1) at /usr/netbsd/src/sys/kern/subr_kmem.c:289
#8  0x809d55d3 in kmem_zalloc (size=64, kmflags=kmflags@entry=1) at 
/usr/netbsd/src/sys/kern/subr_kmem.c:375
#9  0x8076dbd7 in hashmap_rehash (size=, hmap=) at /usr/netbsd/src/sys/net/npf/lpm.c:175
#10 hashmap_insert (len=4, key=0xab8069c78b30, hmap=0x8968800c91a8) at 
/usr/netbsd/src/sys/net/npf/lpm.c:204
#11 lpm_insert (lpm=0x8968800c9008, addr=addr@entry=0x8968828d84d8, 
len=len@entry=4, preflen=preflen@entry=24, val=val@entry=0x8968805daf80)
at /usr/netbsd/src/sys/net/npf/lpm.c:329
#12 0x807654e9 in npf_table_insert (t=t@entry=0x89687bd74318, 
alen=, addr=addr@entry=0x8968828d84d8, mask=24 '\030')
at /usr/netbsd/src/sys/net/npf/npf_tableset.c:536
#13 0x8076085b in npf_mk_table_entries (t=t@entry=0x89687bd74318, 
table=table@entry=0x896883a31150, errdict=errdict@entry=0x89687bc7b3d0)
at /usr/netbsd/src/sys/net/npf/npf_ctl.c:130
#14 0x80760c14 in npf_mk_tables 
(npf_dict=npf_dict@entry=0x896883a31250, 
errdict=errdict@entry=0x89687bc7b3d0,
tblsetp=tblsetp@entry=0xab8069c78cf8, npf=0x896851df8f50) at 
/usr/netbsd/src/sys/net/npf/npf_ctl.c:201
#15 0x80760fc2 in npfctl_load_nvlist (errdict=0x89687bc7b3d0, 
npf_dict=0x896883a31250, npf=0x896851df8f50)
at /usr/netbsd/src/sys/net/npf/npf_ctl.c:535
#16 npfctl_load (npf=0x896851df8f50, cmd=, 
data=0xab8069c78ee0) at /usr/netbsd/src/sys/net/npf/npf_ctl.c:599
#17 0x80a4bf15 in VOP_IOCTL (vp=vp@entry=0x896887d43d28, 
command=command@entry=3222818406, data=data@entry=0xab8069c78ee0,
fflag=, cred=) at 
/usr/netbsd/src/sys/kern/vnode_if.c:610
#18 0x80a43144 in vn_ioctl (fp=0x8968816d3480, com=3222818406, 
data=0xab8069c78ee0) at /usr/netbsd/src/sys/kern/vfs_vnops.c:769
#19 0x809ee05b in sys_ioctl (l=, uap=0xab8069c79000, 
retval=) at /usr/netbsd/src/sys/kern/sys_generic.c:671
#20 0x8024cdd5 in sy_call (rval=0xab8069c78fb0, 
uap=0xab8069c79000, l=0x896884386980, sy=0x81653a90 
)
at /usr/netbsd/src/sys/sys/syscallvar.h:65
#21 sy_invoke (code=54, rval=0xab8069c78fb0, uap=0xab8069c79000, 
l=0x896884386980, sy=0x81653a90 )
at /usr/netbsd/src/sys/sys/syscallvar.h:94
#22 syscall (frame=0xab8069c79000) at 
/usr/netbsd/src/sys/arch/x86/x86/syscall.c:140
#23 0x802096dd in handle_syscall ()

Regards,
Geoff


panic with NPF tables and debug/lockdebug on amd64

2018-09-28 Thread Geoff Wing
Hi,
I'm seeing a kassert panic with NPF tables and kernel options DEBUG/LOCKDEBUG

config:
include "arch/amd64/conf/GENERIC"
options DEBUG
options LOCKDEBUG

My /etc/npf.conf has tables with type hash and type tree

Does anyone else have this configuration working currently?

I'll try it on something where I can debug remotely in a couple of days.

The kassert is at the start of rw_vector_enter()

panic: kernel debugging assertion "pserialize_not_in_read_section()" failed: 
file "/usr/netbsd/src/sys/kern/kern_rwlock.c", line 293
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x16f
ch_voltag_convert_in() at netbsd:ch_voltag_convert_in
rw_enter() at netbsd:rw_enter+0x403
npf_table_lookup() at netbsd:npf_table_lookup+0xfb
npf_cop_table() at netbsd:npf_cop_table+0x63
?() at 81bc5b89
npf_packet_handler() at netbsd:npf_packet_handler+0x231
pfil_run_hooks() at netbsd:pfil_run_hooks+0x12a
ipintr() at netbsd:ipintr+0x4ac
softint_dispatch() at netbsd:softint_dispatch+0xee
DDB lost frame for netbsd:Xsoftintr+0x4f, trying 0xc300675410f0
Xsoftintr() at netbsd:Xsoftintr+0x4f
--- interrupt ---

Regards,
Geoff