Re: 9.99.40: panic: kernel diagnostic assertion "ci->ci_biglock_count == 0" failed

[Andrew Doran <ad%netbsd.org@localhost>]

On Sun, Jan 26, 2020 at 09:09:47PM +0000, Andrew Doran wrote:

> Hi Frank,
> 
> On Sun, Jan 26, 2020 at 09:00:51PM +0100, Frank Kardel wrote:
> 
> > While bulk building pkgsrc with 9.99.42 from Jan 25t I see
> > 
> > panic:kernel diagnostic assertion "curcpu()->ci_biglockcount == 0" failed:
> > ..kern_exit.c, line 209 kernel lock leaked
> > 
> > That happens every couple of thousand packages - sorry no dump (locking
> > against myself as expected).
> 
> Thanks for letting me know.  I will make a change tomorrow to mitigate the
> panic, and allow the badly behaved code to be identified.

Done.  It won't panic any more but should print out a message instead with
the name/address of the routine that last acquired kernel lock.  If you get
some of those messages I'd be very interested to see them.

Thank you,
Andrew

> 
> Andrew
> 
> > 
> > Frank
> > 
> > 
> > 
> > On 01/22/20 17:02, Andrew Doran wrote:
> > > On Tue, Jan 21, 2020 at 07:59:35PM +0000, Andrew Doran wrote:
> > > 
> > > > Hi Thomas,
> > > > 
> > > > On Tue, Jan 21, 2020 at 08:47:44PM +0100, Thomas Klausner wrote:
> > > > 
> > > > > During a bulk build (in rust AFAICT), I got a panic with
> > > > > panic: kernel diagnostic assertion "ci->ci_biglock_count == 0" failed: file "/usr/src/sys/sys/userret.h", line 88
> > > > > 
> > > > > That's this one:
> > > > > 
> > > > > static __inline void
> > > > > mi_userret(struct lwp *l)
> > > > > {
> > > > >          struct cpu_info *ci;
> > > > > 
> > > > >          KPREEMPT_DISABLE(l);
> > > > >          ci = l->l_cpu;
> > > > >          KASSERT(l->l_blcnt == 0);
> > > > >          KASSERT(ci->ci_biglock_count == 0);
> > > > > 
> > > > > 
> > > > > 
> > > > > The backtrace in the crash dump is not very helpful:
> > > > > 
> > > > > (gdb) bt
> > > > > #0  0xffffffff80224315 in cpu_reboot (howto=howto@entry=260, bootstr=bootstr@entry=0x0) at /usr/src/sys/arch/amd64/amd64/machdep.c:720
> > > > > #1  0xffffffff809f5ec3 in kern_reboot (howto=howto@entry=260, bootstr=bootstr@entry=0x0) at /usr/src/sys/kern/kern_reboot.c:61
> > > > > #2  0xffffffff80a37109 in vpanic (fmt=0xffffffff8135e980 "kernel %sassertion \"%s\" failed: file \"%s\", line %d ", ap=ap@entry=0xffffad0928973f48)
> > > > >      at /usr/src/sys/kern/subr_prf.c:336
> > > > > #3  0xffffffff80e7b0b3 in kern_assert (fmt=fmt@entry=0xffffffff8135e980 "kernel %sassertion \"%s\" failed: file \"%s\", line %d ")
> > > > >      at /usr/src/sys/lib/libkern/kern_assert.c:51
> > > > > #4  0xffffffff802568ce in mi_userret (l=0xffffcfc320ca9c00) at /usr/src/sys/sys/userret.h:91
> > > > > #5  userret (l=0xffffcfc320ca9c00) at ./machine/userret.h:81
> > > > > #6  syscall (frame=<optimized out>) at /usr/src/sys/arch/x86/x86/syscall.c:166
> > > > > #7  0xffffffff802096ad in handle_syscall ()
> > > > hannken@ supplied me with a repro for this one so I'm going to look into it
> > > > tomorrow morning.  syzbot has also run into it recently.
> > > This should be fixed now, with the following revisions:
> > > 
> > > cvs rdiff -u -r1.165 -r1.166 src/sys/kern/kern_lock.c
> > > cvs rdiff -u -r1.336 -r1.337 src/sys/kern/kern_synch.c
> > > 
> > > Cheers,
> > > Andrew
> >