From: "Brian J. Murrell" <brian@interlinx.bc.ca>
To: linux-nfs@vger.kernel.org
Subject: mount.nfs4 blocking trying to mount
Date: Tue, 28 Dec 2010 09:30:45 -0500 [thread overview]
Message-ID: <1293546645.10579.83.camel@pc> (raw)
[-- Attachment #1: Type: text/plain, Size: 4697 bytes --]
I have an NFS4 server (2.6.32) and client (2.6.35) and while NFS3 mounts
seem to succeed, NFS4 mounts are blocking as such:
[ 1252.172143] task PC stack pid father
[ 1252.172143] mount.nfs4 D efec3c38 0 10863 10862 0x00000000
[ 1252.172143] efec3c48 00000086 00000002 efec3c38 00000000 c05d99e0 c08c4700 c08c4700
[ 1252.172143] 388152ec 0000011a c08c4700 c08c4700 3880db63 0000011a 00000000 c08c4700
[ 1252.172143] c08c4700 f13758d0 00000001 efec3c7c 00000000 efec3c84 efec3c50 f841ac0c
[ 1252.172143] Call Trace:
[ 1252.172143] [<f841ac0c>] rpc_wait_bit_killable+0x1c/0x40 [sunrpc]
[ 1252.172143] [<c05c823d>] __wait_on_bit+0x4d/0x70
[ 1252.172143] [<f841abf0>] ? rpc_wait_bit_killable+0x0/0x40 [sunrpc]
[ 1252.172143] [<f841abf0>] ? rpc_wait_bit_killable+0x0/0x40 [sunrpc]
[ 1252.172143] [<c05c830b>] out_of_line_wait_on_bit+0xab/0xc0
[ 1252.172143] [<c0165f10>] ? wake_bit_function+0x0/0x50
[ 1252.172143] [<f841b31b>] __rpc_execute+0xdb/0x250 [sunrpc]
[ 1252.248014] [<f841aa17>] ? rpc_init_task+0xd7/0x120 [sunrpc]
[ 1252.248014] [<c016c004>] ? sched_clock_local+0xa4/0x180
[ 1252.248014] [<f841b4fe>] rpc_execute+0x6e/0x80 [sunrpc]
[ 1252.248014] [<f84149af>] rpc_run_task+0x1f/0x30 [sunrpc]
[ 1252.248014] [<f8414abe>] rpc_call_sync+0x3e/0x60 [sunrpc]
[ 1252.248014] [<f8deb6b2>] _nfs4_call_sync+0x22/0x30 [nfs]
[ 1252.248014] [<f8de9795>] nfs4_proc_get_root+0xa5/0x100 [nfs]
[ 1252.248014] [<f8dd36f8>] nfs4_get_rootfh+0x48/0x130 [nfs]
[ 1252.248014] [<f8dd5a33>] ? nfs_alloc_fattr+0x23/0xb0 [nfs]
[ 1252.248014] [<f8dcdf19>] ? nfs4_init_server+0xf9/0x200 [nfs]
[ 1252.248014] [<f8dcd4b4>] nfs4_server_common_setup+0x54/0x170 [nfs]
[ 1252.248014] [<f8dce062>] nfs4_create_server+0x42/0xc0 [nfs]
[ 1252.248014] [<f8dd84eb>] nfs4_remote_get_sb+0x6b/0x250 [nfs]
[ 1252.248014] [<c020fadf>] ? __alloc_percpu+0xf/0x20
[ 1252.248014] [<c0231629>] ? alloc_vfsmnt+0xf9/0x130
[ 1252.248014] [<c021b354>] vfs_kern_mount+0x74/0x1c0
[ 1252.248014] [<f8dd98b9>] nfs_do_root_mount+0x69/0x90 [nfs]
[ 1252.248014] [<f8dd99bf>] nfs4_try_mount+0x3f/0xb0 [nfs]
[ 1252.248014] [<f8dd9ca1>] ? nfs_alloc_parsed_mount_data+0x41/0xa0 [nfs]
[ 1252.248014] [<f8dd9d50>] nfs4_get_sb+0x50/0xd0 [nfs]
[ 1252.248014] [<c0231629>] ? alloc_vfsmnt+0xf9/0x130
[ 1252.248014] [<c021b354>] vfs_kern_mount+0x74/0x1c0
[ 1252.248014] [<c022f9b3>] ? get_fs_type+0x33/0xb0
[ 1252.248014] [<c021b4fe>] do_kern_mount+0x3e/0xe0
[ 1252.248014] [<c0232b2c>] do_mount+0x1dc/0x220
[ 1252.248014] [<c0232bdb>] sys_mount+0x6b/0xa0
[ 1252.248014] [<c05c9cc4>] syscall_call+0x7/0xb
This is a result of:
$ sudo mount -t nfs4 -osec=krb5,exec,dev,suid,rw,bg,rsize=8192,wsize=8192 linux:/usr/local /mnt/tmp
gssds "-vvv" debug when this is done:
handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt10)
handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 '
handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt10)
process_krb5_upcall: service is '<null>'
Full hostname for 'linux.interlinx.bc.ca' is 'linux.interlinx.bc.ca'
Full hostname for 'pc' is 'pc'
Key table entry not found while getting keytab entry for 'root/pc@ILINX'
Key table entry not found while getting keytab entry for 'nfs/pc@ILINX'
Key table entry not found while getting keytab entry for 'host/pc@ILINX'
Success getting keytab entry for nfs/*@ILINX
INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_ILINX' are good until 1293554429
INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_ILINX' are good until 1293554429
using FILE:/tmp/krb5cc_machine_ILINX as credentials cache for machine creds
using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_ILINX
creating context using fsuid 0 (save_uid 0)
creating tcp client for server linux.interlinx.bc.ca
DEBUG: port already set to 2049
creating context with server nfs@linux.interlinx.bc.ca
DEBUG: serialize_krb5_ctx: lucid version!
prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8
doing downcall
svcgssd's "-vvv" output:
entering poll
leaving poll
handling null request
sname = nfs/pc.interlinx.bc.ca@ILINX
DEBUG: serialize_krb5_ctx: lucid version!
prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length
8
doing downcall
mech: krb5, hndl len: 4, ctx len 85, timeout: 1293554429 (35793 from
now), uid: -1, gid: -1, num aux grps: 0:
sending null reply
writing message: \x \x60...9a 1293518696 0 0 \x01000000 \x607...7e9
finished handling null request
entering poll
Any idea why this mount.nfs4 is blocking? This has been working until a
few days ago. Not sure what's changed.
Cheers,
b.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
reply other threads:[~2010-12-28 14:49 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1293546645.10579.83.camel@pc \
--to=brian@interlinx.bc.ca \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.