Possible kqueue related issue on STABLE/RC.

[Konstantin Belousov]

On Mon, Sep 23, 2013 at 03:37:08PM +0200, Patrick Lamaiziere wrote:
> Le Fri, 20 Sep 2013 15:17:05 +0200,
> Patrick Lamaiziere <patfbsd at davenulle.org> a ?crit :
> 
> > Le Thu, 12 Sep 2013 10:36:43 +0300,
> > Konstantin Belousov <kostikbel at gmail.com> a ?crit :
> > 
> > Hello,
> > 
> > > Might be, your issue is that some filesystems do not care about
> > > proper locking mode for the fifos.  UFS carefully disables shared
> > > locking for VFIFO, but it seems ZFS is not.  I can propose the
> > > following band-aid, which could help you.
> > > 
> > > I have no idea is it the same issue as the kqueue panic.
> > > 
> > > diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c
> > > index c53030a..00bd998 100644
> > > --- a/sys/kern/vfs_vnops.c
> > > +++ b/sys/kern/vfs_vnops.c
> > > @@ -267,6 +267,8 @@ vn_open_vnode(struct vnode *vp, int fmode,
> > > struct ucred *cred, return (error);
> > >  		}
> > >  	}
> > > +	if (vp->v_type == VFIFO && VOP_ISLOCKED(vp) !=
> > > LK_EXCLUSIVE)
> > > +		vn_lock(vp, LK_UPGRADE | LK_RETRY);
> > >  	if ((error = VOP_OPEN(vp, fmode, cred, td, fp)) != 0)
> > >  		return (error);
> > >  
> > > @@ -358,7 +360,7 @@ vn_close(vp, flags, file_cred, td)
> > >  	struct mount *mp;
> > >  	int error, lock_flags;
> > >  
> > > -	if (!(flags & FWRITE) && vp->v_mount != NULL &&
> > > +	if (vp->v_type != VFIFO && !(flags & FWRITE) &&
> > > vp->v_mount != NULL && vp->v_mount->mnt_kern_flag &
> > > MNTK_EXTENDED_SHARED) lock_flags = LK_SHARED;
> > >  	else
> > 
> 
> Ok This has been mfced to 9.2-STABLE. But I still see this panic with
> 9-2/STABLE of today (Revision : 255811). This may be better because
> before the box paniced within minutes and now within hours (still using poudriere).
> 
> panic:
> fault code              = supervisor read data, page not present
> instruction pointer     = 0x20:0xffffffff808ebfcd
> stack pointer           = 0x28:0xffffff824c2e0630
> frame pointer           = 0x28:0xffffff824c2e06a0
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 54243 (gvfsd-trash)
> trap number             = 12
> panic: page fault
> cpuid = 2
> KDB: stack backtrace:
> #0 0xffffffff80939ad6 at kdb_backtrace+0x66
> #1 0xffffffff808ffacd at panic+0x1cd
> #2 0xffffffff80cdfbe9 at trap_fatal+0x289
> #3 0xffffffff80cdff4f at trap_pfault+0x20f
> #4 0xffffffff80ce0504 at trap+0x344
> #5 0xffffffff80cc9b43 at calltrap+0x8
> #6 0xffffffff8099d043 at filt_vfsvnode+0xf3
> #7 0xffffffff808c4793 at kqueue_register+0x3e3
> #8 0xffffffff808c4de8 at kern_kevent+0x108
> #9 0xffffffff808c5950 at sys_kevent+0x90
> #10 0xffffffff80cdf3a8 at amd64_syscall+0x5d8
> #11 0xffffffff80cc9e27 at Xfast_syscall+0xf7
> 
> Full core.txt : 
> http://user.lamaiziere.net/patrick/public/vfs_vnode-core.txt.0

For start, please load the core into kgdb and for
frame 8
p *kn

Also, please follow
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html
to recompile kernel with the debugging options and try to recreate the panic.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20130923/493cfcd8/attachment.sig>