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
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!
will fix the problem (in reality, the first patch is just some
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.
section "How to reproduce".
Over to maintainer(s).
For the record, there is a discussion about this PR in freebsd-fs@,
Eygene Ryabinkin ,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
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