[Bug 275905] nfs client: mount becomes unresponsive

From: <bugzilla-noreply_at_freebsd.org>
Date: Sun, 24 Dec 2023 15:50:38 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275905

--- Comment #4 from Rick Macklem <rmacklem@FreeBSD.org> ---
The renew thread RPC (the one that your backtrace shows
as hung in nfsv4_sequencelookup()) would be using the
host/FQDN@REALM entry in the default /etc/krb5.keytab.
(ie. Your TGT would not be used for this, since the
 renew thread runs as "root".)

Could the client's keytab entry be broken somehow?
(As you probably are aware, when you create a new
 keytab for a principal, old keytabs no longer work.)

You could go onto the client and do
# kinit -k host/FQDN
to see that the keytab entry for "host" works ok.
(I am still wondering what will happen if the TGT
 for the keytab expires just after the RPC request
 is sent to the server. I'll look into that.)

There could also be a problem where other RPCs were
using all slots, so the renew thread slept in
nfsv4_sequencelookup() and then another thread needed
the renew thread to do some work.
--> The renew thread should really have a dedicated
    slot in the NFSv4 session, so that no other thread
    can cause it to block.
    --> I might work on a patch for that.

Does this hang occur frequently or was this a "one time"
hang on a mount that usually behaves ok?

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