Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 24 Dec 2023 15:24:52 +0000
From:      bugzilla-noreply@freebsd.org
To:        fs@FreeBSD.org
Subject:   [Bug 275905] nfs client: mount becomes unresponsive
Message-ID:  <bug-275905-3630-vLWJtQrASa@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-275905-3630@https.bugs.freebsd.org/bugzilla/>
References:  <bug-275905-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=3D275905

Rick Macklem <rmacklem@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rmacklem@FreeBSD.org

--- Comment #2 from Rick Macklem <rmacklem@FreeBSD.org> ---
You haven't used the "intr" and/or "soft"
mount options by any chance?

These are guaranteed to break NFSv4 mounts.

The renewthread is stuck in nfsv4_sequencelookup()
because there are no session slots available.
- This can happen for "soft" or "intr" mounts
  because the RPC reply does not get processed
  properly to release the session slot.
- If the mount does not use "soft" nor "intr",
  then there is some other reason that the replies
  are not being processed.
  --> I'll think about this. It might be a side effect
      of a RPCSEC_GSS session being expired so the client
      cannot de-encrypt the RPC reply, or something like
      that. Typically, the RPCSEC_GSS session (not the same
      thing as a NFSv4 session, just to make the terminology
      confusing) expires when the TGT used to acquire it
      expires. It will be re-created upon the next RPC
      if there is a valid TGT, but that might be too
      late for processing of an RPC reply. (With sec=3Dkrb5p
      the reply is encrypted, so it cannot be processed
      without a valid RPCSEC_GSS session.


Once all session slots are in use and no RPC reply is
processed to release one, the mount is hung and the
only fix is to "umount -N <mnt-path>" or reboot the
client machine.

--=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-275905-3630-vLWJtQrASa>