From owner-freebsd-stable@FreeBSD.ORG Mon Sep 23 13:37:17 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7EE49F7E for ; Mon, 23 Sep 2013 13:37:17 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [94.23.254.147]) by mx1.freebsd.org (Postfix) with ESMTP id 4503C2D5C for ; Mon, 23 Sep 2013 13:37:16 +0000 (UTC) Received: from mr129166.localdomain (mr129166.cri.univ-rennes1.fr [129.20.129.166]) by smtp.lamaiziere.net (Postfix) with ESMTPA id A7E6CA631; Mon, 23 Sep 2013 15:37:09 +0200 (CEST) Received: from mr129166 (localhost [127.0.0.1]) by mr129166.localdomain (Postfix) with ESMTP id DFFE91A3; Mon, 23 Sep 2013 15:37:08 +0200 (CEST) Date: Mon, 23 Sep 2013 15:37:08 +0200 From: Patrick Lamaiziere To: Patrick Lamaiziere Subject: Re: Possible kqueue related issue on STABLE/RC. Message-ID: <20130923153708.45c3be3d@mr129166> In-Reply-To: <20130920151705.33aae120@mr129166> References: <20130911171913.GG41229@kib.kiev.ua> <20130912073643.GM41229@kib.kiev.ua> <20130920151705.33aae120@mr129166> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Konstantin Belousov , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 13:37:17 -0000 Le Fri, 20 Sep 2013 15:17:05 +0200, Patrick Lamaiziere a écrit : > Le Thu, 12 Sep 2013 10:36:43 +0300, > Konstantin Belousov 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 Thanks, regards.