Re: locking errors in IPF in netbsd-6

[Chuck Silvers <chuq%chuq.com@localhost>]

On Wed, Mar 13, 2013 at 01:21:37AM +1100, Darren Reed wrote:
> On 11/03/2013 5:28 AM, Chuck Silvers wrote:
> > recently I had occasion to run "ipfstat -f" (which I had never run before)
> > on a netbsd-6 system, and it immediately rebooted.  no dump device 
> > configured, alas.
> >
> > I tried it again later on a test system and ipfstat hung instead:
> >
> > db{0}> t/a  fffffe8429568680
> > trace: pid 328 lid 1 at 0xfffffe811e2e4d00
> > sleepq_block() at netbsd:sleepq_block+0xad
> > turnstile_block() at netbsd:turnstile_block+0x2bb
> > rw_vector_enter() at netbsd:rw_vector_enter+0x1eb
> > ipf_findtoken() at netbsd:ipf_findtoken+0x44
> > fr_nat_ioctl() at netbsd:fr_nat_ioctl+0x4a3
> > cdev_ioctl() at netbsd:cdev_ioctl+0x77
> > VOP_IOCTL() at netbsd:VOP_IOCTL+0x3b
> > vn_ioctl() at netbsd:vn_ioctl+0x76
> > sys_ioctl() at netbsd:sys_ioctl+0x13c
> > syscall() at netbsd:syscall+0xc4
> >
> >
> > there are some obvious locking problems to do with "ipf_tokens"
> > in the version of IPF in the 6.x branch, this lock can be unlocked
> > when it's not held.  does the attached patch look correct?
> >
> > (the more recent version of IPF in -current doesn't have these problems)
> >
> > -Chuck
> 
> Chuck,
> 
> Thanks for picking that up.
> You're right in that the comment is wrong.
> 
> Cheers,
> Darren

great, thanks for confirming.  I've requested the patch be applied to 6.x.
I looked at the version in 5.x, it looks like that version works the way
the comment describes so these changes are not needed there either.

-Chuck