Bug 164261 - [nullfs] [patch] fix panic with NFS served from NULLFS
Summary: [nullfs] [patch] fix panic with NFS served from NULLFS
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.0-CURRENT
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2012-01-17 20:40 UTC by Eygene Ryabinkin
Modified: 2022-10-17 12:35 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eygene Ryabinkin freebsd_committer freebsd_triage 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 freebsd_committer freebsd_triage 2012-01-17 22:13:29 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-fs

Over to maintainer(s).
Comment 2 Eygene Ryabinkin freebsd_committer freebsd_triage 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 freebsd_committer freebsd_triage 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
Comment 4 Graham Perrin freebsd_committer freebsd_triage 2022-10-17 12:35:05 UTC
Keyword: 

    patch
or  patch-ready

– in lieu of summary line prefix: 

    [patch]

* bulk change for the keyword
* summary lines may be edited manually (not in bulk). 

Keyword descriptions and search interface: 

    <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>