Re: panic: Lock filedesc structure not share locked

On Sun, Jun 30, 2013 at 10:27:57AM +0200, Mateusz Guzik wrote:
> On Sun, Jun 30, 2013 at 09:41:50AM +0200, Alexander Leidinger wrote:
> > Hi,
> > 
> > with head as of r252381 on amd64, I got the following panic after
> > starting tmux and creating a 2nd terminal window inside tmux
> > (ctrl-<tmux_command_character> + c):
> > ---snip---
> > panic: Lock filedesc structure not share locked _at_ /space/system/usr_src/sys/kern/kern_descrip.c:3448
> > 
> > cpuid = 2
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff839ee566d0
> > kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff839ee56780
> > vpanic() at vpanic+0x126/frame 0xffffff839ee567c0
> > panic() at panic+0x43/frame 0xffffff839ee56820
> > _sx_assert() at _sx_assert+0x134/frame 0xffffff839ee56830
> > _sx_sunlock() at _sx_sunlock+0x46/frame 0xffffff839ee56860
> > kern_proc_filedesc_out() at kern_proc_filedesc_out+0x420/frame 0xffffff839ee568e0
> > sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x66/frame 0xffffff839ee56950
> > sysctl_root() at sysctl_root+0x1bd/frame 0xffffff839ee569a0
> > userland_sysctl() at userland_sysctl+0x192/frame 0xffffff839ee56a40
> > sys___sysctl() at sys___sysctl+0x74/frame 0xffffff839ee56af0
> > amd64_syscall() at amd64_syscall+0x23c/frame 0xffffff839ee56bf0
> > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff839ee56bf0
> > ---snip---
> > 
> 
> Can you try this (only compile-tested):
> diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c
> index e760fe5..7aa17cd 100644
> --- a/sys/kern/kern_descrip.c
> +++ b/sys/kern/kern_descrip.c
> _at__at_ -3272,6 +3272,8 _at__at_ export_fd_to_sb(void *data, int type, int fd, int fflags, int refcnt,
>  		if (efbuf->remainder < kif->kf_structsize) {
>  			/* Terminate export. */
>  			efbuf->remainder = 0;
> +			if (!locked && efbuf->fdp != NULL)
> +				FILEDESC_SLOCK(efbuf->fdp);
>  			return (0);
>  		}
>  		efbuf->remainder -= kif->kf_structsize;
> 

Mateusz, thank you for spotting this lock leakage. Regardless if this
is the root cause of the reported panic (it looks like it is), this
fix should be definetly committed. Will you do this?

-- 
Mikolaj Golub