From owner-freebsd-fs@freebsd.org Sun Jan 10 15:02:35 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34E54A6B607 for ; Sun, 10 Jan 2016 15:02:35 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id E7B851C7B for ; Sun, 10 Jan 2016 15:02:34 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:kKPE+BaxcsdZGI5opItdRSn/LSx+4OfEezUN459isYplN5qZpcm9bnLW6fgltlLVR4KTs6sC0LqI9fi4EUU7or+/81k6OKRWUBEEjchE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i760zceF13FOBZvIaytQ8iJ35rxj7j60qaQSjsLrQL1Wal1IhSyoFeZnegtqqwmFJwMzADUqGBDYeVcyDAgD1uSmxHh+pX4p8Y7oGwD884mouBaXKjQRIhwY71cAS83KHw44daj4RfZQAaF/XdZXH4+nABFDgLe4Ff9RJin4QXgse8o4iiRPoXTRLs3XTmnp/NxTRbjiyMKMhYk927Kh8hojORQqUTy9FRE34fIbdTNZ7JFdaTHcIZCSA== X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CmBADFcZJW/61jaINehH+IU7NfgWaGD4FPEgEBAQEBAQEBgQmCLYIOI2gBIgINGQJbBIhBn1OPb49oDAEggQGFVYxygUkFjjaIXY83hEOIXESOCwIpDC+EKCCFKoEIAQEB X-IronPort-AV: E=Sophos;i="5.20,548,1444708800"; d="scan'208";a="260502449" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 10 Jan 2016 10:01:57 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id A779815F55D for ; Sun, 10 Jan 2016 10:01:57 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id iOuJ-OrKi0oe for ; Sun, 10 Jan 2016 10:01:57 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 3A86015F565 for ; Sun, 10 Jan 2016 10:01:57 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MG01w8KAlPzk for ; Sun, 10 Jan 2016 10:01:57 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 1A2FA15F55D for ; Sun, 10 Jan 2016 10:01:57 -0500 (EST) Date: Sun, 10 Jan 2016 10:01:57 -0500 (EST) From: Rick Macklem To: FreeBSD Filesystems Message-ID: <1696608910.154845456.1452438117036.JavaMail.zimbra@uoguelph.ca> Subject: panic ffs_truncate3 (maybe fuse being evil) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF43 (Win)/8.0.9_GA_6191) Thread-Topic: panic ffs_truncate3 (maybe fuse being evil) Thread-Index: PA5DUOP2RagN6MZVMgYY+16xjDN8aw== X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2016 15:02:35 -0000 Hi, When fooling around with GlusterFS, I can get this panic intermittently. (I had a couple yesterday.) This happens on a Dec. 5, 2015 head kernel. panic: ffs_truncate3 - backtrace without the numbers (I just scribbled it off the screen) ffs_truncate() ufs_inactive() VOP_INACTIVE_APV() vinactive() vputx() kern_unlinkat() So, at a glance, it seems that either b_dirty.bv_cnt or b_clean.bv_cnt is non-zero. (There is another case for the panic, but I thought it was less likely?) So, I'm wondering if this might be another side effect of r291460, since after that a new vnode isn't completely zero'd out? However, shouldn't bo_dirty.bv_cnt and bo_clean.bv_cnt be zero when a vnode is recycled? Does this make sense or do some fields of v_bufobj need to be zero'd out by getnewvnode()? GlusterFS is using fuse and I suspect that fuse isn't cleaning out the buffers under some circumstance (I already noticed that there isn't any code in its fuse_vnop_reclaim() and I vaguely recall that there are conditions where VOP_INACTIVE() gets skipped, so that VOP_RECLAIM() has to check for anything that would have been done by VOP_INACTIVE() and do it, if it isn't already done.) Anyhow, if others have thoughts on this (or other hunches w.r.t. what could cause this panic(), please let me know. Thanks, rick