[Bug 275905] nfs client: mount becomes unresponsive

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275905

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=krb5p
      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.

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