|Summary:||[nullfs] [patch] fix panic with NFS served from NULLFS|
|Product:||Base System||Reporter:||Eygene Ryabinkin <rea>|
|Component:||kern||Assignee:||freebsd-bugs (Nobody) <bugs>|
|Severity:||Affects Only Me|
Description Eygene Ryabinkin 2012-01-17 20:40:14 UTC
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! 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. How-To-Repeat: See http://codelabs.ru/fbsd/prs/2012-jan-nullfs-LK_SHARED/README.txt section "How to reproduce".
Comment 1 Mark Linimon 2012-01-17 22:13:29 UTC
Responsible Changed From-To: freebsd-bugs->freebsd-fs Over to maintainer(s).
Comment 2 Eygene Ryabinkin 2012-01-18 10:36:04 UTC
For the record, there is a discussion about this PR in freebsd-fs@, http://lists.freebsd.org/pipermail/freebsd-fs/2012-January/013438.html -- Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
Comment 3 Eitan Adler 2017-12-31 07:59:22 UTC
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped