From owner-freebsd-bugs@FreeBSD.ORG Tue Jan 17 20:40:15 2012 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D81A1065673; Tue, 17 Jan 2012 20:40:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EF4058FC1F; Tue, 17 Jan 2012 20:40:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0HKeEOp059167; Tue, 17 Jan 2012 20:40:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0HKeEYQ059166; Tue, 17 Jan 2012 20:40:14 GMT (envelope-from gnats) Resent-Date: Tue, 17 Jan 2012 20:40:14 GMT Resent-Message-Id: <201201172040.q0HKeEYQ059166@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@freebsd.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Cc: kib@freebsd.org, attilio@freebsd.org, rmacklem@freebsd.org Resent-Reply-To: FreeBSD-gnats-submit@freebsd.org, Eygene Ryabinkin Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 497CB1065673 for ; Tue, 17 Jan 2012 20:40:01 +0000 (UTC) (envelope-from rea@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id E39258FC13 for ; Tue, 17 Jan 2012 20:40:00 +0000 (UTC) Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtps (TLSv1:CAMELLIA256-SHA:256) id 1RnFeH-000C7h-5g for FreeBSD-gnats-submit@freebsd.org; Tue, 17 Jan 2012 23:28:54 +0300 Message-Id: <20120117202853.19F65DA81C@void.codelabs.ru> Date: Wed, 18 Jan 2012 00:28:53 +0400 (MSK) From: Eygene Ryabinkin To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.113 X-GNATS-Notify: kib@freebsd.org, attilio@freebsd.org, rmacklem@freebsd.org Cc: Subject: kern/164261: [patch] fix panic with NFS served from NULLFS X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eygene Ryabinkin List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 20:40:15 -0000 >Number: 164261 >Category: kern >Synopsis: [patch] fix panic with NFS served from NULLFS >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Jan 17 20:40:14 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Eygene Ryabinkin >Release: FreeBSD 10.0-CURRENT amd64 >Organization: Code Labs >Environment: System: FreeBSD 10.0-CURRENT, FreeBSD 9.0-STABLE >Description: When one exports NULLFS filesystems via NFS, he can face kernel panics if external clients use readdir+ feature and are accessing same directories simultaneously. The example of the backtrace can be obtained at http://codelabs.ru/fbsd/prs/2012-jan-nullfs-LK_SHARED/panic-backtrace.txt This backtrace is from 9.x as of December 2011. The real problem is that the thread that loses the race in null_nodeget (/sys/fs/nullfs/null_subr.c) will put the native lock (vp->v_vnlock = &vp->v_lock) to the nullfs vnode that should be destroyed (because the thread lost the race). And null_reclaim (/sys/fs/nullfs/null_vnops.c) will try to lock vnode's v_lock in the exclusive mode. This will lead to panic, because v_vnlock is already locked at the time of VOP_RECLAIM processing and we have v_vnlock that points to v_lock. Bingo! >How-To-Repeat: See http://codelabs.ru/fbsd/prs/2012-jan-nullfs-LK_SHARED/README.txt section "How to reproduce". >Fix: Patches http://codelabs.ru/fbsd/prs/2012-jan-nullfs-LK_SHARED/0001-NULLFS-properly-destroy-node-hash.patch and http://codelabs.ru/fbsd/prs/2012-jan-nullfs-LK_SHARED/0002-NULLFS-fix-panics-when-lowervp-is-locked-with-LK_SHA.patch will fix the problem (in reality, the first patch is just some nitpicking). I had tested this patch on my 10-CURRENT machine; tomorrow I intend to test in on the 9.x production NFS server with 300-400 clients. >Release-Note: >Audit-Trail: >Unformatted: