>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: _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
