Date: Wed, 18 Jan 2012 00:28:53 +0400 (MSK) From: Eygene Ryabinkin <rea@freebsd.org> To: FreeBSD-gnats-submit@freebsd.org Subject: kern/164261: [patch] fix panic with NFS served from NULLFS Message-ID: <20120117202853.19F65DA81C@void.codelabs.ru> Resent-Message-ID: <201201172040.q0HKeEYQ059166@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120117202853.19F65DA81C>