Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Aug 2018 12:20:20 +0000
From:      bugzilla-noreply@freebsd.org
To:        fs@FreeBSD.org
Subject:   [Bug 230752] panic: excl->share in newnfs_request
Message-ID:  <bug-230752-3630-Gbca3XgBID@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-230752-3630@https.bugs.freebsd.org/bugzilla/>
References:  <bug-230752-3630@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230752

--- Comment #6 from commit-hook@freebsd.org ---
A commit references this bug:

Author: rmacklem
Date: Wed Aug 22 12:20:10 UTC 2018
New revision: 338192
URL: https://svnweb.freebsd.org/changeset/base/338192

Log:
  Revert r320757 since it can cause "excl->shared" panics.

  PR#230752 shows a panic where an nfsd thread tries to do soconnect() on
  the AF_LOCAL socket used by the nfsuserd while already holding an
  exclusive lock on it. I am not 100% sure how this happens, but since an
  AF_LOCAL socket is in the file system namespace it is conceivable that it
  could lock it and then attempt an upcall to the nfsuserd.
  However, reverting r320757 stops the nfsuserd from using an AF_LOCAL
  socket, so it should avoid any such panic().
  r320757 did fix a problem with running the nfsuserd when jails were
  enabled, but that can be dealt with less elegantly by allowing the
  use of an alternate address instead of 127.0.0.1.
  The gssd daemon also uses an AF_LOCAL socket, but it will do upcalls
  before the nfsd thread processes the RPC, so I think it should not
  be suseptible to this problem.

  PR:           230752

Changes:
  head/usr.sbin/nfsuserd/nfsuserd.c

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-230752-3630-Gbca3XgBID>