On 04/11/2011 10:40 PM, Jiri Slaby wrote: > Ccing Bryan > > On 04/11/2011 10:40 PM, Jiri Slaby wrote: >> On 04/07/2011 08:42 AM, Jiri Slaby wrote: >>> On 04/06/2011 10:44 PM, Myklebust, Trond wrote: >>>> On Sat, 2011-04-02 at 10:56 +0200, Jiri Slaby wrote: >>>>> On 03/31/2011 11:48 PM, akpm@xxxxxxxxxxxxxxxxxxxx wrote: >>>>>> The mm-of-the-moment snapshot 2011-03-31-14-48 has been uploaded to >>>>> >>>>> Hi, nfs client is defunct in this kernel. Tcpdump says: >>>>> 10:51:55.489717 IP 10.20.11.33.759945860 > 10.20.3.2.2049: 132 getattr >>>>> fh 0,0/24 >>>>> 10:51:55.515927 IP 10.20.3.2.2049 > 10.20.11.33.759945860: reply ok 44 >>>>> getattr ERROR: Operation not permitted >>>>> 10:51:55.515949 IP 10.20.11.33.921 > 10.20.3.2.2049: Flags [.], ack >>>>> 3569361440, win 115, options [nop,nop,TS val 599750 ecr 255058541], >>>> length 0 >>>>> 10:52:04.130310 IP 10.20.11.33.793500292 > 10.20.3.2.2049: 76 getattr fh >>>>> 0,0/24 >>>>> 10:52:04.152178 IP 10.20.3.2.2049 > 10.20.11.33.793500292: reply ok 44 >>>>> getattr ERROR: Operation not permitted >>>>> >>>>> If I run the same mount command (mount -oro,intr host:dir mountpoint) >>>>> from within a virtual machine with 2.6.38.2 there, everything mounts OK. >>>> >>>> Does the attached patch help? >>> >>> No, still the operation not permitted in the tcpdump output and no mount. >> >> The next tree from 20110411 still doesn't work. The topmost commit in >> fs/nfs/namespace.c is: >> commit 418875900e3de4831c84f86ae4756690dac5be77 >> Author: Bryan Schumaker <bjschuma@xxxxxxxxxx> >> Date: Wed Apr 6 14:33:28 2011 -0400 >> >> NFS: Fix a signed vs. unsigned secinfo bug >> >> >> I bisected it to (in vanilla already): >> >> 8f70e95f9f4159184f557a1db60c909d7c1bd2e3 is the first bad commit >> commit 8f70e95f9f4159184f557a1db60c909d7c1bd2e3 >> Author: Bryan Schumaker <bjschuma@xxxxxxxxxx> >> Date: Thu Mar 24 17:12:31 2011 +0000 >> >> NFS: Determine initial mount security >> >> When sec=<something> is not presented as a mount option, >> we should attempt to determine what security flavor the >> server is using. >> >> Signed-off-by: Bryan Schumaker <bjschuma@xxxxxxxxxx> >> Signed-off-by: Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> >> >> :040000 040000 8e5a640b37e00f0df21e1d9cd9aff160df2d5938 >> 0152daa67bc8d12e32cda5f4a036807d2e380392 M fs >> :040000 040000 f74aa33f8597cb82cd0fd7d90d84e0660b7f5804 >> 527bc0ca6975cedc7e684b45dc9961f8aaf1207a M include >> :040000 040000 87559d2f211ea905343a86c8551b6610dd239891 >> 7e4ee0e5eddf12474b6de9e7fdb6218b6165bdb2 M net Sorry for an extra message. I've just found out that there appears messages in dmesg: [ 58.656048] RPC: AUTH_GSS upcall timed out. [ 58.656050] Please check user daemon is running. [ 88.656065] RPC: AUTH_GSS upcall timed out. [ 88.656068] Please check user daemon is running. [ 118.656077] RPC: AUTH_GSS upcall timed out. [ 118.656080] Please check user daemon is running. [ 148.656049] RPC: AUTH_GSS upcall timed out. [ 148.656052] Please check user daemon is running. [ 178.656046] RPC: AUTH_GSS upcall timed out. [ 178.656049] Please check user daemon is running. I instrumented the code and it's stuck with trying RPC_AUTH_GSS_KRB5. I don't use GSS at all. regards, -- js suse labs -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
