* [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945 @ 2007-09-07 10:02 Kamalesh Babulal 2007-09-07 15:29 ` J. Bruce Fields 2007-09-07 23:56 ` Michal Piotrowski 0 siblings, 2 replies; 14+ messages in thread From: Kamalesh Babulal @ 2007-09-07 10:02 UTC (permalink / raw) To: linux-kernel; +Cc: bfields, neilb, nfs Sep 7 11:42:49 p55lp2 kernel: kernel BUG at fs/nfs/nfs4xdr.c:945! Sep 7 11:42:49 p55lp2 kernel: Oops: Exception in kernel mode, sig: 5 [#1] Sep 7 11:42:49 p55lp2 kernel: SMP NR_CPUS=128 NUMA pSeries Sep 7 11:42:49 p55lp2 kernel: Modules linked in: nfs lockd nfs_acl sunrpc ipv6 loop dm_mod ibmveth sg ibmvscsic sd_mod scsi_mod Sep 7 11:42:49 p55lp2 kernel: NIP: d000000000378044 LR: d000000000378034 CTR: 80000000001c5840 Sep 7 11:42:49 p55lp2 kernel: REGS: c0000000d971b050 TRAP: 0700 Not tainted (2.6.23-rc5-ppc64) Sep 7 11:42:49 p55lp2 kernel: MSR: 8000000000029032 <EE,ME,IR,DR> CR: 28000444 XER: 00000014 Sep 7 11:42:49 p55lp2 kernel: TASK = c000000002787740[11508] 'fsstress' THREAD: c0000000d9718000 CPU: 1 Sep 7 11:42:49 p55lp2 kernel: GPR00: 0000000000000001 c0000000d971b2d0 d0000000003bd648 0000000000000037 Sep 7 11:42:49 p55lp2 kernel: GPR04: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Sep 7 11:42:49 p55lp2 kernel: GPR08: 0000000000000002 c000000000616538 c0000000ef7afb58 c000000000616540 Sep 7 11:42:49 p55lp2 kernel: GPR12: 0000000000004000 c0000000005e4a80 0000000000000000 00000000200b2510 Sep 7 11:42:49 p55lp2 kernel: GPR16: 0000000020105550 00000000200b2534 000000002008c15c 0000000000000001 Sep 7 11:42:49 p55lp2 kernel: GPR20: 0000000000000000 0000000000000001 fffffffffffff000 c0000000d971ba30 Sep 7 11:42:49 p55lp2 kernel: GPR24: d00000000034f524 c0000000dc4f8054 c0000000d971b7d0 c0000000d9d313f0 Sep 7 11:42:49 p55lp2 kernel: GPR28: 0000000000000276 0000000022000000 d0000000003b8d78 0000000000000000 Sep 7 11:42:49 p55lp2 kernel: NIP [d000000000378044] .encode_lookup+0x6c/0xbc [nfs] Sep 7 11:42:49 p55lp2 kernel: LR [d000000000378034] .encode_lookup+0x5c/0xbc [nfs] Sep 7 11:42:49 p55lp2 kernel: Call Trace: Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b2d0] [d000000000378034] .encode_lookup+0x5c/0xbc [nfs] (unreliable) Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b370] [d000000000379f8c] .nfs4_xdr_enc_lookup+0x78/0xbc [nfs] Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b440] [d000000000314534] .rpcauth_wrap_req+0xe4/0x124 [sunrpc] Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b4f0] [d00000000030a790] .call_transmit+0x218/0x2b8 [sunrpc] Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b590] [d0000000003124d8] .__rpc_execute+0xd4/0x368 [sunrpc] Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b630] [d00000000030b114] .rpc_do_run_task+0xc8/0x104 [sunrpc] Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b6e0] [d00000000030b224] .rpc_call_sync+0x2c/0x64 [sunrpc] Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b760] [d00000000036ef04] ._nfs4_proc_lookupfh+0xd4/0x124 [nfs] Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b850] [d0000000003719a0] ._nfs4_proc_lookup+0x80/0x21c [nfs] Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b910] [d000000000371ba4] .nfs4_proc_lookup+0x68/0xac [nfs] Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b9c0] [d000000000354bf4] .nfs_lookup+0x158/0x334 [nfs] Sep 7 11:42:49 p55lp2 kernel: [c0000000d971bbc0] [c0000000000f3a28] .lookup_hash+0xfc/0x140 Sep 7 11:42:49 p55lp2 kernel: [c0000000d971bc60] [c0000000000f7b28] .sys_renameat+0x164/0x228 Sep 7 11:42:49 p55lp2 kernel: [c0000000d971be30] [c000000000008534] syscall_exit+0x0/0x40 Sep 7 11:42:49 p55lp2 kernel: Instruction dump: Sep 7 11:42:49 p55lp2 kernel: e8410028 7fa4eb78 7c7f1b79 7fb80026 40820014 e8be83a8 e87e8350 4800c5f9 Sep 7 11:42:49 p55lp2 kernel: e8410028 7fb80120 7c180026 54001ffe <0b000000> 3800000f 7b850020 387f0008 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945 2007-09-07 10:02 [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945 Kamalesh Babulal @ 2007-09-07 15:29 ` J. Bruce Fields 2007-09-10 18:02 ` Kamalesh Babulal 2007-09-07 23:56 ` Michal Piotrowski 1 sibling, 1 reply; 14+ messages in thread From: J. Bruce Fields @ 2007-09-07 15:29 UTC (permalink / raw) To: Kamalesh Babulal; +Cc: linux-kernel, neilb, nfs, Trond Myklebust On Fri, Sep 07, 2007 at 03:32:32PM +0530, Kamalesh Babulal wrote: > Sep 7 11:42:49 p55lp2 kernel: kernel BUG at fs/nfs/nfs4xdr.c:945! That's the first line of encode_lookup: static int encode_lookup(struct xdr_stream *xdr, const struct qstr *name) { int len = name->len; __be32 *p; RESERVE_SPACE(8 + len); So len is either very large, or it's just garbage. Do you know if fsstress is trying to do something with a particularly long filename here? --b. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945 2007-09-07 15:29 ` J. Bruce Fields @ 2007-09-10 18:02 ` Kamalesh Babulal 0 siblings, 0 replies; 14+ messages in thread From: Kamalesh Babulal @ 2007-09-10 18:02 UTC (permalink / raw) To: J. Bruce Fields; +Cc: linux-kernel, neilb, nfs, Trond Myklebust J. Bruce Fields wrote: > On Fri, Sep 07, 2007 at 03:32:32PM +0530, Kamalesh Babulal wrote: > >> Sep 7 11:42:49 p55lp2 kernel: kernel BUG at fs/nfs/nfs4xdr.c:945! >> > > That's the first line of encode_lookup: > > static int encode_lookup(struct xdr_stream *xdr, const struct qstr *name) > { > int len = name->len; > __be32 *p; > > RESERVE_SPACE(8 + len); > > So len is either very large, or it's just garbage. Do you know if > fsstress is trying to do something with a particularly long filename > here? > > --b. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > Hi, The fsstress creates random file names up to 1024 characters long. Thanks & regards, Kamalesh Babulal. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945 2007-09-07 10:02 [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945 Kamalesh Babulal 2007-09-07 15:29 ` J. Bruce Fields @ 2007-09-07 23:56 ` Michal Piotrowski 2007-09-08 22:12 ` [NFS] " Trond Myklebust 2007-09-10 12:56 ` Kamalesh Babulal 1 sibling, 2 replies; 14+ messages in thread From: Michal Piotrowski @ 2007-09-07 23:56 UTC (permalink / raw) To: Kamalesh Babulal; +Cc: linux-kernel, bfields, neilb, nfs Hi, On 07/09/2007, Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote: > Sep 7 11:42:49 p55lp2 kernel: kernel BUG at fs/nfs/nfs4xdr.c:945! > Sep 7 11:42:49 p55lp2 kernel: Oops: Exception in kernel mode, sig: 5 [#1] > Sep 7 11:42:49 p55lp2 kernel: SMP NR_CPUS=128 NUMA pSeries > Sep 7 11:42:49 p55lp2 kernel: Modules linked in: nfs lockd nfs_acl > sunrpc ipv6 loop dm_mod ibmveth sg ibmvscsic sd_mod scsi_mod > Sep 7 11:42:49 p55lp2 kernel: NIP: d000000000378044 LR: > d000000000378034 CTR: 80000000001c5840 > Sep 7 11:42:49 p55lp2 kernel: REGS: c0000000d971b050 TRAP: 0700 Not > tainted (2.6.23-rc5-ppc64) > Sep 7 11:42:49 p55lp2 kernel: MSR: 8000000000029032 <EE,ME,IR,DR> CR: > 28000444 XER: 00000014 > Sep 7 11:42:49 p55lp2 kernel: TASK = c000000002787740[11508] 'fsstress' > THREAD: c0000000d9718000 CPU: 1 > Sep 7 11:42:49 p55lp2 kernel: GPR00: 0000000000000001 c0000000d971b2d0 > d0000000003bd648 0000000000000037 > Sep 7 11:42:49 p55lp2 kernel: GPR04: 0000000000000000 0000000000000000 > 0000000000000000 0000000000000000 > Sep 7 11:42:49 p55lp2 kernel: GPR08: 0000000000000002 c000000000616538 > c0000000ef7afb58 c000000000616540 > Sep 7 11:42:49 p55lp2 kernel: GPR12: 0000000000004000 c0000000005e4a80 > 0000000000000000 00000000200b2510 > Sep 7 11:42:49 p55lp2 kernel: GPR16: 0000000020105550 00000000200b2534 > 000000002008c15c 0000000000000001 > Sep 7 11:42:49 p55lp2 kernel: GPR20: 0000000000000000 0000000000000001 > fffffffffffff000 c0000000d971ba30 > Sep 7 11:42:49 p55lp2 kernel: GPR24: d00000000034f524 c0000000dc4f8054 > c0000000d971b7d0 c0000000d9d313f0 > Sep 7 11:42:49 p55lp2 kernel: GPR28: 0000000000000276 0000000022000000 > d0000000003b8d78 0000000000000000 > Sep 7 11:42:49 p55lp2 kernel: NIP [d000000000378044] > .encode_lookup+0x6c/0xbc [nfs] > Sep 7 11:42:49 p55lp2 kernel: LR [d000000000378034] > .encode_lookup+0x5c/0xbc [nfs] > Sep 7 11:42:49 p55lp2 kernel: Call Trace: > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b2d0] [d000000000378034] > .encode_lookup+0x5c/0xbc [nfs] (unreliable) > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b370] [d000000000379f8c] > .nfs4_xdr_enc_lookup+0x78/0xbc [nfs] > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b440] [d000000000314534] > .rpcauth_wrap_req+0xe4/0x124 [sunrpc] > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b4f0] [d00000000030a790] > .call_transmit+0x218/0x2b8 [sunrpc] > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b590] [d0000000003124d8] > .__rpc_execute+0xd4/0x368 [sunrpc] > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b630] [d00000000030b114] > .rpc_do_run_task+0xc8/0x104 [sunrpc] > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b6e0] [d00000000030b224] > .rpc_call_sync+0x2c/0x64 [sunrpc] > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b760] [d00000000036ef04] > ._nfs4_proc_lookupfh+0xd4/0x124 [nfs] > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b850] [d0000000003719a0] > ._nfs4_proc_lookup+0x80/0x21c [nfs] > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b910] [d000000000371ba4] > .nfs4_proc_lookup+0x68/0xac [nfs] > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b9c0] [d000000000354bf4] > .nfs_lookup+0x158/0x334 [nfs] > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971bbc0] [c0000000000f3a28] > .lookup_hash+0xfc/0x140 > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971bc60] [c0000000000f7b28] > .sys_renameat+0x164/0x228 > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971be30] [c000000000008534] > syscall_exit+0x0/0x40 > Sep 7 11:42:49 p55lp2 kernel: Instruction dump: > Sep 7 11:42:49 p55lp2 kernel: e8410028 7fa4eb78 7c7f1b79 7fb80026 > 40820014 e8be83a8 e87e8350 4800c5f9 > Sep 7 11:42:49 p55lp2 kernel: e8410028 7fb80120 7c180026 54001ffe > <0b000000> 3800000f 7b850020 387f0008 Is this a post 2.6.22 regression? Have you tried 2.6.23-rc5-git1? (There are a few nfs fixes) Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [NFS] [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945 2007-09-07 23:56 ` Michal Piotrowski @ 2007-09-08 22:12 ` Trond Myklebust 2007-09-10 8:11 ` suzuki 2007-09-10 13:06 ` Kamalesh Babulal 2007-09-10 12:56 ` Kamalesh Babulal 1 sibling, 2 replies; 14+ messages in thread From: Trond Myklebust @ 2007-09-08 22:12 UTC (permalink / raw) To: Michal Piotrowski; +Cc: Kamalesh Babulal, bfields, neilb, nfs, linux-kernel [-- Attachment #1: Type: text/plain, Size: 4118 bytes --] On Sat, 2007-09-08 at 01:56 +0200, Michal Piotrowski wrote: > Hi, > > On 07/09/2007, Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote: > > Sep 7 11:42:49 p55lp2 kernel: kernel BUG at fs/nfs/nfs4xdr.c:945! > > Sep 7 11:42:49 p55lp2 kernel: Oops: Exception in kernel mode, sig: 5 [#1] > > Sep 7 11:42:49 p55lp2 kernel: SMP NR_CPUS=128 NUMA pSeries > > Sep 7 11:42:49 p55lp2 kernel: Modules linked in: nfs lockd nfs_acl > > sunrpc ipv6 loop dm_mod ibmveth sg ibmvscsic sd_mod scsi_mod > > Sep 7 11:42:49 p55lp2 kernel: NIP: d000000000378044 LR: > > d000000000378034 CTR: 80000000001c5840 > > Sep 7 11:42:49 p55lp2 kernel: REGS: c0000000d971b050 TRAP: 0700 Not > > tainted (2.6.23-rc5-ppc64) > > Sep 7 11:42:49 p55lp2 kernel: MSR: 8000000000029032 <EE,ME,IR,DR> CR: > > 28000444 XER: 00000014 > > Sep 7 11:42:49 p55lp2 kernel: TASK = c000000002787740[11508] 'fsstress' > > THREAD: c0000000d9718000 CPU: 1 > > Sep 7 11:42:49 p55lp2 kernel: GPR00: 0000000000000001 c0000000d971b2d0 > > d0000000003bd648 0000000000000037 > > Sep 7 11:42:49 p55lp2 kernel: GPR04: 0000000000000000 0000000000000000 > > 0000000000000000 0000000000000000 > > Sep 7 11:42:49 p55lp2 kernel: GPR08: 0000000000000002 c000000000616538 > > c0000000ef7afb58 c000000000616540 > > Sep 7 11:42:49 p55lp2 kernel: GPR12: 0000000000004000 c0000000005e4a80 > > 0000000000000000 00000000200b2510 > > Sep 7 11:42:49 p55lp2 kernel: GPR16: 0000000020105550 00000000200b2534 > > 000000002008c15c 0000000000000001 > > Sep 7 11:42:49 p55lp2 kernel: GPR20: 0000000000000000 0000000000000001 > > fffffffffffff000 c0000000d971ba30 > > Sep 7 11:42:49 p55lp2 kernel: GPR24: d00000000034f524 c0000000dc4f8054 > > c0000000d971b7d0 c0000000d9d313f0 > > Sep 7 11:42:49 p55lp2 kernel: GPR28: 0000000000000276 0000000022000000 > > d0000000003b8d78 0000000000000000 > > Sep 7 11:42:49 p55lp2 kernel: NIP [d000000000378044] > > .encode_lookup+0x6c/0xbc [nfs] > > Sep 7 11:42:49 p55lp2 kernel: LR [d000000000378034] > > .encode_lookup+0x5c/0xbc [nfs] > > Sep 7 11:42:49 p55lp2 kernel: Call Trace: > > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b2d0] [d000000000378034] > > .encode_lookup+0x5c/0xbc [nfs] (unreliable) > > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b370] [d000000000379f8c] > > .nfs4_xdr_enc_lookup+0x78/0xbc [nfs] > > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b440] [d000000000314534] > > .rpcauth_wrap_req+0xe4/0x124 [sunrpc] > > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b4f0] [d00000000030a790] > > .call_transmit+0x218/0x2b8 [sunrpc] > > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b590] [d0000000003124d8] > > .__rpc_execute+0xd4/0x368 [sunrpc] > > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b630] [d00000000030b114] > > .rpc_do_run_task+0xc8/0x104 [sunrpc] > > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b6e0] [d00000000030b224] > > .rpc_call_sync+0x2c/0x64 [sunrpc] > > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b760] [d00000000036ef04] > > ._nfs4_proc_lookupfh+0xd4/0x124 [nfs] > > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b850] [d0000000003719a0] > > ._nfs4_proc_lookup+0x80/0x21c [nfs] > > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b910] [d000000000371ba4] > > .nfs4_proc_lookup+0x68/0xac [nfs] > > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b9c0] [d000000000354bf4] > > .nfs_lookup+0x158/0x334 [nfs] > > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971bbc0] [c0000000000f3a28] > > .lookup_hash+0xfc/0x140 > > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971bc60] [c0000000000f7b28] > > .sys_renameat+0x164/0x228 > > Sep 7 11:42:49 p55lp2 kernel: [c0000000d971be30] [c000000000008534] > > syscall_exit+0x0/0x40 > > Sep 7 11:42:49 p55lp2 kernel: Instruction dump: > > Sep 7 11:42:49 p55lp2 kernel: e8410028 7fa4eb78 7c7f1b79 7fb80026 > > 40820014 e8be83a8 e87e8350 4800c5f9 > > Sep 7 11:42:49 p55lp2 kernel: e8410028 7fb80120 7c180026 54001ffe > > <0b000000> 3800000f 7b850020 387f0008 > > Is this a post 2.6.22 regression? Have you tried 2.6.23-rc5-git1? > (There are a few nfs fixes) > > Regards, > Michal It looks like a bug that has been there at least since 2.6.18. Could you see if this fixes it? Trond [-- Attachment #2: Type: message/rfc822, Size: 997 bytes --] From: Trond Myklebust <Trond.Myklebust@netapp.com> Subject: No Subject Date: Sun, 9 Sep 2007 00:10:51 +0200 Message-ID: <1189289549.13713.5.camel@localhost.localdomain> It doesn't look as if the NFSv4 name length is being initialised correctly in the struct nfs_server. We need to limit any entry there to NFS4_MAXNAMLEN. Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> --- fs/nfs/client.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/fs/nfs/client.c b/fs/nfs/client.c index a49f9fe..54068fb 100644 --- a/fs/nfs/client.c +++ b/fs/nfs/client.c @@ -928,6 +928,9 @@ static int nfs4_init_server(struct nfs_server *server, error = nfs_init_server_rpcclient(server, authflavour); + if (server->namelen == 0 || server->namelen > NFS4_MAXNAMLEN) + server->namelen = NFS4_MAXNAMLEN; + /* Done */ dprintk("<-- nfs4_init_server() = %d\n", error); return error; ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [NFS] [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945 2007-09-08 22:12 ` [NFS] " Trond Myklebust @ 2007-09-10 8:11 ` suzuki 2007-09-10 21:03 ` Trond Myklebust 2007-09-10 13:06 ` Kamalesh Babulal 1 sibling, 1 reply; 14+ messages in thread From: suzuki @ 2007-09-10 8:11 UTC (permalink / raw) To: Trond Myklebust Cc: Michal Piotrowski, Kamalesh Babulal, bfields, neilb, nfs, linux-kernel, ffilz, Poornima Hi I have been trying to debug this issue from my side and could find the following. The pathconf() request gets a reply with : pathinfo.max_namelen = (unsiged int) -1 pathinfo.max_link = 255 Is this really an expected answer from a server for a proper connection ( for mount requests on an exported dir) ? Is there something that needs to be fixed at server side ? Thanks Suzuki Trond Myklebust wrote: > On Sat, 2007-09-08 at 01:56 +0200, Michal Piotrowski wrote: >> Hi, >> >> On 07/09/2007, Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote: >>> Sep 7 11:42:49 p55lp2 kernel: kernel BUG at fs/nfs/nfs4xdr.c:945! >>> Sep 7 11:42:49 p55lp2 kernel: Oops: Exception in kernel mode, sig: 5 [#1] >>> Sep 7 11:42:49 p55lp2 kernel: SMP NR_CPUS=128 NUMA pSeries >>> Sep 7 11:42:49 p55lp2 kernel: Modules linked in: nfs lockd nfs_acl >>> sunrpc ipv6 loop dm_mod ibmveth sg ibmvscsic sd_mod scsi_mod >>> Sep 7 11:42:49 p55lp2 kernel: NIP: d000000000378044 LR: >>> d000000000378034 CTR: 80000000001c5840 >>> Sep 7 11:42:49 p55lp2 kernel: REGS: c0000000d971b050 TRAP: 0700 Not >>> tainted (2.6.23-rc5-ppc64) >>> Sep 7 11:42:49 p55lp2 kernel: MSR: 8000000000029032 <EE,ME,IR,DR> CR: >>> 28000444 XER: 00000014 >>> Sep 7 11:42:49 p55lp2 kernel: TASK = c000000002787740[11508] 'fsstress' >>> THREAD: c0000000d9718000 CPU: 1 >>> Sep 7 11:42:49 p55lp2 kernel: GPR00: 0000000000000001 c0000000d971b2d0 >>> d0000000003bd648 0000000000000037 >>> Sep 7 11:42:49 p55lp2 kernel: GPR04: 0000000000000000 0000000000000000 >>> 0000000000000000 0000000000000000 >>> Sep 7 11:42:49 p55lp2 kernel: GPR08: 0000000000000002 c000000000616538 >>> c0000000ef7afb58 c000000000616540 >>> Sep 7 11:42:49 p55lp2 kernel: GPR12: 0000000000004000 c0000000005e4a80 >>> 0000000000000000 00000000200b2510 >>> Sep 7 11:42:49 p55lp2 kernel: GPR16: 0000000020105550 00000000200b2534 >>> 000000002008c15c 0000000000000001 >>> Sep 7 11:42:49 p55lp2 kernel: GPR20: 0000000000000000 0000000000000001 >>> fffffffffffff000 c0000000d971ba30 >>> Sep 7 11:42:49 p55lp2 kernel: GPR24: d00000000034f524 c0000000dc4f8054 >>> c0000000d971b7d0 c0000000d9d313f0 >>> Sep 7 11:42:49 p55lp2 kernel: GPR28: 0000000000000276 0000000022000000 >>> d0000000003b8d78 0000000000000000 >>> Sep 7 11:42:49 p55lp2 kernel: NIP [d000000000378044] >>> .encode_lookup+0x6c/0xbc [nfs] >>> Sep 7 11:42:49 p55lp2 kernel: LR [d000000000378034] >>> .encode_lookup+0x5c/0xbc [nfs] >>> Sep 7 11:42:49 p55lp2 kernel: Call Trace: >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b2d0] [d000000000378034] >>> .encode_lookup+0x5c/0xbc [nfs] (unreliable) >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b370] [d000000000379f8c] >>> .nfs4_xdr_enc_lookup+0x78/0xbc [nfs] >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b440] [d000000000314534] >>> .rpcauth_wrap_req+0xe4/0x124 [sunrpc] >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b4f0] [d00000000030a790] >>> .call_transmit+0x218/0x2b8 [sunrpc] >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b590] [d0000000003124d8] >>> .__rpc_execute+0xd4/0x368 [sunrpc] >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b630] [d00000000030b114] >>> .rpc_do_run_task+0xc8/0x104 [sunrpc] >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b6e0] [d00000000030b224] >>> .rpc_call_sync+0x2c/0x64 [sunrpc] >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b760] [d00000000036ef04] >>> ._nfs4_proc_lookupfh+0xd4/0x124 [nfs] >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b850] [d0000000003719a0] >>> ._nfs4_proc_lookup+0x80/0x21c [nfs] >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b910] [d000000000371ba4] >>> .nfs4_proc_lookup+0x68/0xac [nfs] >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b9c0] [d000000000354bf4] >>> .nfs_lookup+0x158/0x334 [nfs] >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971bbc0] [c0000000000f3a28] >>> .lookup_hash+0xfc/0x140 >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971bc60] [c0000000000f7b28] >>> .sys_renameat+0x164/0x228 >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971be30] [c000000000008534] >>> syscall_exit+0x0/0x40 >>> Sep 7 11:42:49 p55lp2 kernel: Instruction dump: >>> Sep 7 11:42:49 p55lp2 kernel: e8410028 7fa4eb78 7c7f1b79 7fb80026 >>> 40820014 e8be83a8 e87e8350 4800c5f9 >>> Sep 7 11:42:49 p55lp2 kernel: e8410028 7fb80120 7c180026 54001ffe >>> <0b000000> 3800000f 7b850020 387f0008 >> Is this a post 2.6.22 regression? Have you tried 2.6.23-rc5-git1? >> (There are a few nfs fixes) >> >> Regards, >> Michal > > It looks like a bug that has been there at least since 2.6.18. Could you > see if this fixes it? > > Trond > > > > > ------------------------------------------------------------------------ > > Subject: > No Subject > From: > Trond Myklebust <Trond.Myklebust@netapp.com> > Date: > Sun, 9 Sep 2007 00:10:51 +0200 > > > It doesn't look as if the NFSv4 name length is being initialised correctly > in the struct nfs_server. We need to limit any entry there to > NFS4_MAXNAMLEN. > > Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> > --- > > fs/nfs/client.c | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/fs/nfs/client.c b/fs/nfs/client.c > index a49f9fe..54068fb 100644 > --- a/fs/nfs/client.c > +++ b/fs/nfs/client.c > @@ -928,6 +928,9 @@ static int nfs4_init_server(struct nfs_server *server, > > error = nfs_init_server_rpcclient(server, authflavour); > > + if (server->namelen == 0 || server->namelen > NFS4_MAXNAMLEN) > + server->namelen = NFS4_MAXNAMLEN; > + > /* Done */ > dprintk("<-- nfs4_init_server() = %d\n", error); > return error; ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [NFS] [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945 2007-09-10 8:11 ` suzuki @ 2007-09-10 21:03 ` Trond Myklebust 2007-09-11 4:56 ` suzuki 0 siblings, 1 reply; 14+ messages in thread From: Trond Myklebust @ 2007-09-10 21:03 UTC (permalink / raw) To: suzuki Cc: Michal Piotrowski, Kamalesh Babulal, bfields, neilb, nfs, linux-kernel, ffilz, Poornima On Mon, 2007-09-10 at 13:41 +0530, suzuki wrote: > Hi > > I have been trying to debug this issue from my side and could find the > following. > > The pathconf() request gets a reply with : > > pathinfo.max_namelen = (unsiged int) -1 > pathinfo.max_link = 255 > > Is this really an expected answer from a server for a proper connection > ( for mount requests on an exported dir) ? Is there something that needs > to be fixed at server side ? I assume that this is with my patch applied? Yes: as long as the kernel sets NAME_MAX to 255, then the above is expected behaviour. Trond ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [NFS] [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945 2007-09-10 21:03 ` Trond Myklebust @ 2007-09-11 4:56 ` suzuki 0 siblings, 0 replies; 14+ messages in thread From: suzuki @ 2007-09-11 4:56 UTC (permalink / raw) To: Trond Myklebust Cc: Michal Piotrowski, Kamalesh Babulal, bfields, neilb, nfs, linux-kernel, ffilz, Poornima Trond Myklebust wrote: > On Mon, 2007-09-10 at 13:41 +0530, suzuki wrote: >> Hi >> >> I have been trying to debug this issue from my side and could find the >> following. >> >> The pathconf() request gets a reply with : >> >> pathinfo.max_namelen = (unsiged int) -1 >> pathinfo.max_link = 255 >> >> Is this really an expected answer from a server for a proper connection >> ( for mount requests on an exported dir) ? Is there something that needs >> to be fixed at server side ? > > I assume that this is with my patch applied? No. This is without your patch. So I am trying to debug why the server is sending a -1 ! (which sounds like an error ?) Thanks Suzuki K P IBM Linux Technology Centre Yes: as long as the kernel > sets NAME_MAX to 255, then the above is expected behaviour. > > Trond > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [NFS] [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945 2007-09-08 22:12 ` [NFS] " Trond Myklebust 2007-09-10 8:11 ` suzuki @ 2007-09-10 13:06 ` Kamalesh Babulal 2007-09-19 17:31 ` Trond Myklebust 1 sibling, 1 reply; 14+ messages in thread From: Kamalesh Babulal @ 2007-09-10 13:06 UTC (permalink / raw) To: Trond Myklebust; +Cc: Michal Piotrowski, bfields, neilb, nfs, linux-kernel Trond Myklebust wrote: > On Sat, 2007-09-08 at 01:56 +0200, Michal Piotrowski wrote: > >> Hi, >> >> On 07/09/2007, Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote: >> >>> Sep 7 11:42:49 p55lp2 kernel: kernel BUG at fs/nfs/nfs4xdr.c:945! >>> Sep 7 11:42:49 p55lp2 kernel: Oops: Exception in kernel mode, sig: 5 [#1] >>> Sep 7 11:42:49 p55lp2 kernel: SMP NR_CPUS=128 NUMA pSeries >>> Sep 7 11:42:49 p55lp2 kernel: Modules linked in: nfs lockd nfs_acl >>> sunrpc ipv6 loop dm_mod ibmveth sg ibmvscsic sd_mod scsi_mod >>> Sep 7 11:42:49 p55lp2 kernel: NIP: d000000000378044 LR: >>> d000000000378034 CTR: 80000000001c5840 >>> Sep 7 11:42:49 p55lp2 kernel: REGS: c0000000d971b050 TRAP: 0700 Not >>> tainted (2.6.23-rc5-ppc64) >>> Sep 7 11:42:49 p55lp2 kernel: MSR: 8000000000029032 <EE,ME,IR,DR> CR: >>> 28000444 XER: 00000014 >>> Sep 7 11:42:49 p55lp2 kernel: TASK = c000000002787740[11508] 'fsstress' >>> THREAD: c0000000d9718000 CPU: 1 >>> Sep 7 11:42:49 p55lp2 kernel: GPR00: 0000000000000001 c0000000d971b2d0 >>> d0000000003bd648 0000000000000037 >>> Sep 7 11:42:49 p55lp2 kernel: GPR04: 0000000000000000 0000000000000000 >>> 0000000000000000 0000000000000000 >>> Sep 7 11:42:49 p55lp2 kernel: GPR08: 0000000000000002 c000000000616538 >>> c0000000ef7afb58 c000000000616540 >>> Sep 7 11:42:49 p55lp2 kernel: GPR12: 0000000000004000 c0000000005e4a80 >>> 0000000000000000 00000000200b2510 >>> Sep 7 11:42:49 p55lp2 kernel: GPR16: 0000000020105550 00000000200b2534 >>> 000000002008c15c 0000000000000001 >>> Sep 7 11:42:49 p55lp2 kernel: GPR20: 0000000000000000 0000000000000001 >>> fffffffffffff000 c0000000d971ba30 >>> Sep 7 11:42:49 p55lp2 kernel: GPR24: d00000000034f524 c0000000dc4f8054 >>> c0000000d971b7d0 c0000000d9d313f0 >>> Sep 7 11:42:49 p55lp2 kernel: GPR28: 0000000000000276 0000000022000000 >>> d0000000003b8d78 0000000000000000 >>> Sep 7 11:42:49 p55lp2 kernel: NIP [d000000000378044] >>> .encode_lookup+0x6c/0xbc [nfs] >>> Sep 7 11:42:49 p55lp2 kernel: LR [d000000000378034] >>> .encode_lookup+0x5c/0xbc [nfs] >>> Sep 7 11:42:49 p55lp2 kernel: Call Trace: >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b2d0] [d000000000378034] >>> .encode_lookup+0x5c/0xbc [nfs] (unreliable) >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b370] [d000000000379f8c] >>> .nfs4_xdr_enc_lookup+0x78/0xbc [nfs] >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b440] [d000000000314534] >>> .rpcauth_wrap_req+0xe4/0x124 [sunrpc] >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b4f0] [d00000000030a790] >>> .call_transmit+0x218/0x2b8 [sunrpc] >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b590] [d0000000003124d8] >>> .__rpc_execute+0xd4/0x368 [sunrpc] >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b630] [d00000000030b114] >>> .rpc_do_run_task+0xc8/0x104 [sunrpc] >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b6e0] [d00000000030b224] >>> .rpc_call_sync+0x2c/0x64 [sunrpc] >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b760] [d00000000036ef04] >>> ._nfs4_proc_lookupfh+0xd4/0x124 [nfs] >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b850] [d0000000003719a0] >>> ._nfs4_proc_lookup+0x80/0x21c [nfs] >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b910] [d000000000371ba4] >>> .nfs4_proc_lookup+0x68/0xac [nfs] >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b9c0] [d000000000354bf4] >>> .nfs_lookup+0x158/0x334 [nfs] >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971bbc0] [c0000000000f3a28] >>> .lookup_hash+0xfc/0x140 >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971bc60] [c0000000000f7b28] >>> .sys_renameat+0x164/0x228 >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971be30] [c000000000008534] >>> syscall_exit+0x0/0x40 >>> Sep 7 11:42:49 p55lp2 kernel: Instruction dump: >>> Sep 7 11:42:49 p55lp2 kernel: e8410028 7fa4eb78 7c7f1b79 7fb80026 >>> 40820014 e8be83a8 e87e8350 4800c5f9 >>> Sep 7 11:42:49 p55lp2 kernel: e8410028 7fb80120 7c180026 54001ffe >>> <0b000000> 3800000f 7b850020 387f0008 >>> >> Is this a post 2.6.22 regression? Have you tried 2.6.23-rc5-git1? >> (There are a few nfs fixes) >> >> Regards, >> Michal >> > > It looks like a bug that has been there at least since 2.6.18. Could you > see if this fixes it? > > Trond > > > > > ------------------------------------------------------------------------ > > Subject: > No Subject > From: > Trond Myklebust <Trond.Myklebust@netapp.com> > Date: > Sun, 9 Sep 2007 00:10:51 +0200 > > > It doesn't look as if the NFSv4 name length is being initialised correctly > in the struct nfs_server. We need to limit any entry there to > NFS4_MAXNAMLEN. > > Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> > --- > > fs/nfs/client.c | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/fs/nfs/client.c b/fs/nfs/client.c > index a49f9fe..54068fb 100644 > --- a/fs/nfs/client.c > +++ b/fs/nfs/client.c > @@ -928,6 +928,9 @@ static int nfs4_init_server(struct nfs_server *server, > > error = nfs_init_server_rpcclient(server, authflavour); > > + if (server->namelen == 0 || server->namelen > NFS4_MAXNAMLEN) > + server->namelen = NFS4_MAXNAMLEN; > + > /* Done */ > dprintk("<-- nfs4_init_server() = %d\n", error); > return error; > Hi Trond, After applying the patch, i get the same kernel Bug cpu 0x0: Vector: 700 (Program Check) at [c0000000e2d5f050] pc: d000000000841668: .encode_lookup+0x6c/0xbc [nfs] lr: d000000000841658: .encode_lookup+0x5c/0xbc [nfs] sp: c0000000e2d5f2d0 msr: 8000000000029032 current = 0xc0000000e6358790 paca = 0xc0000000005ead00 pid = 3452, comm = fsstress kernel BUG at fs/nfs/nfs4xdr.c:945! enter ? for help [c0000000e2d5f370] d0000000008435b0 .nfs4_xdr_enc_lookup+0x78/0xbc [nfs] [c0000000e2d5f440] d00000000019a2d4 .rpcauth_wrap_req+0xe4/0x124 [sunrpc] [c0000000e2d5f4f0] d000000000190774 .call_transmit+0x218/0x2b8 [sunrpc] [c0000000e2d5f590] d000000000198308 .__rpc_execute+0xd4/0x34c [sunrpc] [c0000000e2d5f630] d0000000001910f8 .rpc_do_run_task+0xc8/0x104 [sunrpc] [c0000000e2d5f6e0] d000000000191208 .rpc_call_sync+0x2c/0x64 [sunrpc] [c0000000e2d5f760] d0000000008386f0 ._nfs4_proc_lookupfh+0xd4/0x124 [nfs] [c0000000e2d5f850] d00000000083b14c ._nfs4_proc_lookup+0x80/0x21c [nfs] [c0000000e2d5f910] d00000000083b350 .nfs4_proc_lookup+0x68/0xac [nfs] [c0000000e2d5f9c0] d00000000081ea40 .nfs_lookup+0x158/0x314 [nfs] [c0000000e2d5fbc0] c0000000000f4ba8 .lookup_hash+0xfc/0x140 [c0000000e2d5fc60] c0000000000f8a70 .sys_renameat+0x164/0x228 [c0000000e2d5fe30] c000000000008534 syscall_exit+0x0/0x40 --- Exception: c01 (System Call) at 000000000feeb3d4 SP (ffe805a0) is in userspace Thanks & Regards, Kamalesh Babulal. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [NFS] [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945 2007-09-10 13:06 ` Kamalesh Babulal @ 2007-09-19 17:31 ` Trond Myklebust 2007-09-24 19:01 ` Kamalesh Babulal 0 siblings, 1 reply; 14+ messages in thread From: Trond Myklebust @ 2007-09-19 17:31 UTC (permalink / raw) To: Kamalesh Babulal; +Cc: Michal Piotrowski, bfields, neilb, nfs, linux-kernel On Mon, 2007-09-10 at 18:36 +0530, Kamalesh Babulal wrote: > Trond Myklebust wrote: > > On Sat, 2007-09-08 at 01:56 +0200, Michal Piotrowski wrote: > > > >> Hi, > >> > >> On 07/09/2007, Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote: > >> > >>> Sep 7 11:42:49 p55lp2 kernel: kernel BUG at fs/nfs/nfs4xdr.c:945! > >>> Sep 7 11:42:49 p55lp2 kernel: Oops: Exception in kernel mode, sig: 5 [#1] > >>> Sep 7 11:42:49 p55lp2 kernel: SMP NR_CPUS=128 NUMA pSeries > >>> Sep 7 11:42:49 p55lp2 kernel: Modules linked in: nfs lockd nfs_acl > >>> sunrpc ipv6 loop dm_mod ibmveth sg ibmvscsic sd_mod scsi_mod > >>> Sep 7 11:42:49 p55lp2 kernel: NIP: d000000000378044 LR: > >>> d000000000378034 CTR: 80000000001c5840 > >>> Sep 7 11:42:49 p55lp2 kernel: REGS: c0000000d971b050 TRAP: 0700 Not > >>> tainted (2.6.23-rc5-ppc64) > >>> Sep 7 11:42:49 p55lp2 kernel: MSR: 8000000000029032 <EE,ME,IR,DR> CR: > >>> 28000444 XER: 00000014 > >>> Sep 7 11:42:49 p55lp2 kernel: TASK = c000000002787740[11508] 'fsstress' > >>> THREAD: c0000000d9718000 CPU: 1 > >>> Sep 7 11:42:49 p55lp2 kernel: GPR00: 0000000000000001 c0000000d971b2d0 > >>> d0000000003bd648 0000000000000037 > >>> Sep 7 11:42:49 p55lp2 kernel: GPR04: 0000000000000000 0000000000000000 > >>> 0000000000000000 0000000000000000 > >>> Sep 7 11:42:49 p55lp2 kernel: GPR08: 0000000000000002 c000000000616538 > >>> c0000000ef7afb58 c000000000616540 > >>> Sep 7 11:42:49 p55lp2 kernel: GPR12: 0000000000004000 c0000000005e4a80 > >>> 0000000000000000 00000000200b2510 > >>> Sep 7 11:42:49 p55lp2 kernel: GPR16: 0000000020105550 00000000200b2534 > >>> 000000002008c15c 0000000000000001 > >>> Sep 7 11:42:49 p55lp2 kernel: GPR20: 0000000000000000 0000000000000001 > >>> fffffffffffff000 c0000000d971ba30 > >>> Sep 7 11:42:49 p55lp2 kernel: GPR24: d00000000034f524 c0000000dc4f8054 > >>> c0000000d971b7d0 c0000000d9d313f0 > >>> Sep 7 11:42:49 p55lp2 kernel: GPR28: 0000000000000276 0000000022000000 > >>> d0000000003b8d78 0000000000000000 > >>> Sep 7 11:42:49 p55lp2 kernel: NIP [d000000000378044] > >>> .encode_lookup+0x6c/0xbc [nfs] > >>> Sep 7 11:42:49 p55lp2 kernel: LR [d000000000378034] > >>> .encode_lookup+0x5c/0xbc [nfs] > >>> Sep 7 11:42:49 p55lp2 kernel: Call Trace: > >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b2d0] [d000000000378034] > >>> .encode_lookup+0x5c/0xbc [nfs] (unreliable) > >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b370] [d000000000379f8c] > >>> .nfs4_xdr_enc_lookup+0x78/0xbc [nfs] > >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b440] [d000000000314534] > >>> .rpcauth_wrap_req+0xe4/0x124 [sunrpc] > >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b4f0] [d00000000030a790] > >>> .call_transmit+0x218/0x2b8 [sunrpc] > >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b590] [d0000000003124d8] > >>> .__rpc_execute+0xd4/0x368 [sunrpc] > >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b630] [d00000000030b114] > >>> .rpc_do_run_task+0xc8/0x104 [sunrpc] > >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b6e0] [d00000000030b224] > >>> .rpc_call_sync+0x2c/0x64 [sunrpc] > >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b760] [d00000000036ef04] > >>> ._nfs4_proc_lookupfh+0xd4/0x124 [nfs] > >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b850] [d0000000003719a0] > >>> ._nfs4_proc_lookup+0x80/0x21c [nfs] > >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b910] [d000000000371ba4] > >>> .nfs4_proc_lookup+0x68/0xac [nfs] > >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b9c0] [d000000000354bf4] > >>> .nfs_lookup+0x158/0x334 [nfs] > >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971bbc0] [c0000000000f3a28] > >>> .lookup_hash+0xfc/0x140 > >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971bc60] [c0000000000f7b28] > >>> .sys_renameat+0x164/0x228 > >>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971be30] [c000000000008534] > >>> syscall_exit+0x0/0x40 > >>> Sep 7 11:42:49 p55lp2 kernel: Instruction dump: > >>> Sep 7 11:42:49 p55lp2 kernel: e8410028 7fa4eb78 7c7f1b79 7fb80026 > >>> 40820014 e8be83a8 e87e8350 4800c5f9 > >>> Sep 7 11:42:49 p55lp2 kernel: e8410028 7fb80120 7c180026 54001ffe > >>> <0b000000> 3800000f 7b850020 387f0008 > >>> > >> Is this a post 2.6.22 regression? Have you tried 2.6.23-rc5-git1? > >> (There are a few nfs fixes) > >> > >> Regards, > >> Michal > >> > > > > It looks like a bug that has been there at least since 2.6.18. Could you > > see if this fixes it? > > > > Trond > > > > > > > > > > ------------------------------------------------------------------------ > > > > Subject: > > No Subject > > From: > > Trond Myklebust <Trond.Myklebust@netapp.com> > > Date: > > Sun, 9 Sep 2007 00:10:51 +0200 > > > > > > It doesn't look as if the NFSv4 name length is being initialised correctly > > in the struct nfs_server. We need to limit any entry there to > > NFS4_MAXNAMLEN. > > > > Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> > > --- > > > > fs/nfs/client.c | 3 +++ > > 1 files changed, 3 insertions(+), 0 deletions(-) > > > > diff --git a/fs/nfs/client.c b/fs/nfs/client.c > > index a49f9fe..54068fb 100644 > > --- a/fs/nfs/client.c > > +++ b/fs/nfs/client.c > > @@ -928,6 +928,9 @@ static int nfs4_init_server(struct nfs_server *server, > > > > error = nfs_init_server_rpcclient(server, authflavour); > > > > + if (server->namelen == 0 || server->namelen > NFS4_MAXNAMLEN) > > + server->namelen = NFS4_MAXNAMLEN; > > + > > /* Done */ > > dprintk("<-- nfs4_init_server() = %d\n", error); > > return error; > > > Hi Trond, > > After applying the patch, i get the same kernel Bug > > cpu 0x0: Vector: 700 (Program Check) at [c0000000e2d5f050] > pc: d000000000841668: .encode_lookup+0x6c/0xbc [nfs] > lr: d000000000841658: .encode_lookup+0x5c/0xbc [nfs] > sp: c0000000e2d5f2d0 > msr: 8000000000029032 > current = 0xc0000000e6358790 > paca = 0xc0000000005ead00 > pid = 3452, comm = fsstress > kernel BUG at fs/nfs/nfs4xdr.c:945! > enter ? for help > [c0000000e2d5f370] d0000000008435b0 .nfs4_xdr_enc_lookup+0x78/0xbc [nfs] > [c0000000e2d5f440] d00000000019a2d4 .rpcauth_wrap_req+0xe4/0x124 [sunrpc] > [c0000000e2d5f4f0] d000000000190774 .call_transmit+0x218/0x2b8 [sunrpc] > [c0000000e2d5f590] d000000000198308 .__rpc_execute+0xd4/0x34c [sunrpc] > [c0000000e2d5f630] d0000000001910f8 .rpc_do_run_task+0xc8/0x104 [sunrpc] > [c0000000e2d5f6e0] d000000000191208 .rpc_call_sync+0x2c/0x64 [sunrpc] > [c0000000e2d5f760] d0000000008386f0 ._nfs4_proc_lookupfh+0xd4/0x124 [nfs] > [c0000000e2d5f850] d00000000083b14c ._nfs4_proc_lookup+0x80/0x21c [nfs] > [c0000000e2d5f910] d00000000083b350 .nfs4_proc_lookup+0x68/0xac [nfs] > [c0000000e2d5f9c0] d00000000081ea40 .nfs_lookup+0x158/0x314 [nfs] > [c0000000e2d5fbc0] c0000000000f4ba8 .lookup_hash+0xfc/0x140 > [c0000000e2d5fc60] c0000000000f8a70 .sys_renameat+0x164/0x228 > [c0000000e2d5fe30] c000000000008534 syscall_exit+0x0/0x40 > --- Exception: c01 (System Call) at 000000000feeb3d4 > SP (ffe805a0) is in userspace > > > Thanks & Regards, > Kamalesh Babulal. I'm mystified. I'm quite unable to reproduce this on my own setup: the ENAMETOOLONG error reporting mechanism prevents me from even getting near the above bug. Could you add a little printk into the 'encode_lookup' routine on line 944 of fs/nfs/nfs4xdr.c to display the value of 'len'? Cheers Trond ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [NFS] [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945 2007-09-19 17:31 ` Trond Myklebust @ 2007-09-24 19:01 ` Kamalesh Babulal 2007-09-24 21:26 ` Trond Myklebust 0 siblings, 1 reply; 14+ messages in thread From: Kamalesh Babulal @ 2007-09-24 19:01 UTC (permalink / raw) To: Trond Myklebust; +Cc: Michal Piotrowski, bfields, neilb, nfs, linux-kernel Trond Myklebust wrote: > On Mon, 2007-09-10 at 18:36 +0530, Kamalesh Babulal wrote: >> Trond Myklebust wrote: >>> On Sat, 2007-09-08 at 01:56 +0200, Michal Piotrowski wrote: >>> >>>> Hi, >>>> >>>> On 07/09/2007, Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote: >>>> >>>>> Sep 7 11:42:49 p55lp2 kernel: kernel BUG at fs/nfs/nfs4xdr.c:945! >>>>> Sep 7 11:42:49 p55lp2 kernel: Oops: Exception in kernel mode, sig: 5 [#1] >>>>> Sep 7 11:42:49 p55lp2 kernel: SMP NR_CPUS=128 NUMA pSeries >>>>> Sep 7 11:42:49 p55lp2 kernel: Modules linked in: nfs lockd nfs_acl >>>>> sunrpc ipv6 loop dm_mod ibmveth sg ibmvscsic sd_mod scsi_mod >>>>> Sep 7 11:42:49 p55lp2 kernel: NIP: d000000000378044 LR: >>>>> d000000000378034 CTR: 80000000001c5840 >>>>> Sep 7 11:42:49 p55lp2 kernel: REGS: c0000000d971b050 TRAP: 0700 Not >>>>> tainted (2.6.23-rc5-ppc64) >>>>> Sep 7 11:42:49 p55lp2 kernel: MSR: 8000000000029032 <EE,ME,IR,DR> CR: >>>>> 28000444 XER: 00000014 >>>>> Sep 7 11:42:49 p55lp2 kernel: TASK = c000000002787740[11508] 'fsstress' >>>>> THREAD: c0000000d9718000 CPU: 1 >>>>> Sep 7 11:42:49 p55lp2 kernel: GPR00: 0000000000000001 c0000000d971b2d0 >>>>> d0000000003bd648 0000000000000037 >>>>> Sep 7 11:42:49 p55lp2 kernel: GPR04: 0000000000000000 0000000000000000 >>>>> 0000000000000000 0000000000000000 >>>>> Sep 7 11:42:49 p55lp2 kernel: GPR08: 0000000000000002 c000000000616538 >>>>> c0000000ef7afb58 c000000000616540 >>>>> Sep 7 11:42:49 p55lp2 kernel: GPR12: 0000000000004000 c0000000005e4a80 >>>>> 0000000000000000 00000000200b2510 >>>>> Sep 7 11:42:49 p55lp2 kernel: GPR16: 0000000020105550 00000000200b2534 >>>>> 000000002008c15c 0000000000000001 >>>>> Sep 7 11:42:49 p55lp2 kernel: GPR20: 0000000000000000 0000000000000001 >>>>> fffffffffffff000 c0000000d971ba30 >>>>> Sep 7 11:42:49 p55lp2 kernel: GPR24: d00000000034f524 c0000000dc4f8054 >>>>> c0000000d971b7d0 c0000000d9d313f0 >>>>> Sep 7 11:42:49 p55lp2 kernel: GPR28: 0000000000000276 0000000022000000 >>>>> d0000000003b8d78 0000000000000000 >>>>> Sep 7 11:42:49 p55lp2 kernel: NIP [d000000000378044] >>>>> .encode_lookup+0x6c/0xbc [nfs] >>>>> Sep 7 11:42:49 p55lp2 kernel: LR [d000000000378034] >>>>> .encode_lookup+0x5c/0xbc [nfs] >>>>> Sep 7 11:42:49 p55lp2 kernel: Call Trace: >>>>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b2d0] [d000000000378034] >>>>> .encode_lookup+0x5c/0xbc [nfs] (unreliable) >>>>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b370] [d000000000379f8c] >>>>> .nfs4_xdr_enc_lookup+0x78/0xbc [nfs] >>>>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b440] [d000000000314534] >>>>> .rpcauth_wrap_req+0xe4/0x124 [sunrpc] >>>>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b4f0] [d00000000030a790] >>>>> .call_transmit+0x218/0x2b8 [sunrpc] >>>>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b590] [d0000000003124d8] >>>>> .__rpc_execute+0xd4/0x368 [sunrpc] >>>>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b630] [d00000000030b114] >>>>> .rpc_do_run_task+0xc8/0x104 [sunrpc] >>>>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b6e0] [d00000000030b224] >>>>> .rpc_call_sync+0x2c/0x64 [sunrpc] >>>>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b760] [d00000000036ef04] >>>>> ._nfs4_proc_lookupfh+0xd4/0x124 [nfs] >>>>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b850] [d0000000003719a0] >>>>> ._nfs4_proc_lookup+0x80/0x21c [nfs] >>>>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b910] [d000000000371ba4] >>>>> .nfs4_proc_lookup+0x68/0xac [nfs] >>>>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b9c0] [d000000000354bf4] >>>>> .nfs_lookup+0x158/0x334 [nfs] >>>>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971bbc0] [c0000000000f3a28] >>>>> .lookup_hash+0xfc/0x140 >>>>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971bc60] [c0000000000f7b28] >>>>> .sys_renameat+0x164/0x228 >>>>> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971be30] [c000000000008534] >>>>> syscall_exit+0x0/0x40 >>>>> Sep 7 11:42:49 p55lp2 kernel: Instruction dump: >>>>> Sep 7 11:42:49 p55lp2 kernel: e8410028 7fa4eb78 7c7f1b79 7fb80026 >>>>> 40820014 e8be83a8 e87e8350 4800c5f9 >>>>> Sep 7 11:42:49 p55lp2 kernel: e8410028 7fb80120 7c180026 54001ffe >>>>> <0b000000> 3800000f 7b850020 387f0008 >>>>> >>>> Is this a post 2.6.22 regression? Have you tried 2.6.23-rc5-git1? >>>> (There are a few nfs fixes) >>>> >>>> Regards, >>>> Michal >>>> >>> It looks like a bug that has been there at least since 2.6.18. Could you >>> see if this fixes it? >>> >>> Trond >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> Subject: >>> No Subject >>> From: >>> Trond Myklebust <Trond.Myklebust@netapp.com> >>> Date: >>> Sun, 9 Sep 2007 00:10:51 +0200 >>> >>> >>> It doesn't look as if the NFSv4 name length is being initialised correctly >>> in the struct nfs_server. We need to limit any entry there to >>> NFS4_MAXNAMLEN. >>> >>> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> >>> --- >>> >>> fs/nfs/client.c | 3 +++ >>> 1 files changed, 3 insertions(+), 0 deletions(-) >>> >>> diff --git a/fs/nfs/client.c b/fs/nfs/client.c >>> index a49f9fe..54068fb 100644 >>> --- a/fs/nfs/client.c >>> +++ b/fs/nfs/client.c >>> @@ -928,6 +928,9 @@ static int nfs4_init_server(struct nfs_server *server, >>> >>> error = nfs_init_server_rpcclient(server, authflavour); >>> >>> + if (server->namelen == 0 || server->namelen > NFS4_MAXNAMLEN) >>> + server->namelen = NFS4_MAXNAMLEN; >>> + >>> /* Done */ >>> dprintk("<-- nfs4_init_server() = %d\n", error); >>> return error; >>> >> Hi Trond, >> >> After applying the patch, i get the same kernel Bug >> >> cpu 0x0: Vector: 700 (Program Check) at [c0000000e2d5f050] >> pc: d000000000841668: .encode_lookup+0x6c/0xbc [nfs] >> lr: d000000000841658: .encode_lookup+0x5c/0xbc [nfs] >> sp: c0000000e2d5f2d0 >> msr: 8000000000029032 >> current = 0xc0000000e6358790 >> paca = 0xc0000000005ead00 >> pid = 3452, comm = fsstress >> kernel BUG at fs/nfs/nfs4xdr.c:945! >> enter ? for help >> [c0000000e2d5f370] d0000000008435b0 .nfs4_xdr_enc_lookup+0x78/0xbc [nfs] >> [c0000000e2d5f440] d00000000019a2d4 .rpcauth_wrap_req+0xe4/0x124 [sunrpc] >> [c0000000e2d5f4f0] d000000000190774 .call_transmit+0x218/0x2b8 [sunrpc] >> [c0000000e2d5f590] d000000000198308 .__rpc_execute+0xd4/0x34c [sunrpc] >> [c0000000e2d5f630] d0000000001910f8 .rpc_do_run_task+0xc8/0x104 [sunrpc] >> [c0000000e2d5f6e0] d000000000191208 .rpc_call_sync+0x2c/0x64 [sunrpc] >> [c0000000e2d5f760] d0000000008386f0 ._nfs4_proc_lookupfh+0xd4/0x124 [nfs] >> [c0000000e2d5f850] d00000000083b14c ._nfs4_proc_lookup+0x80/0x21c [nfs] >> [c0000000e2d5f910] d00000000083b350 .nfs4_proc_lookup+0x68/0xac [nfs] >> [c0000000e2d5f9c0] d00000000081ea40 .nfs_lookup+0x158/0x314 [nfs] >> [c0000000e2d5fbc0] c0000000000f4ba8 .lookup_hash+0xfc/0x140 >> [c0000000e2d5fc60] c0000000000f8a70 .sys_renameat+0x164/0x228 >> [c0000000e2d5fe30] c000000000008534 syscall_exit+0x0/0x40 >> --- Exception: c01 (System Call) at 000000000feeb3d4 >> SP (ffe805a0) is in userspace >> >> >> Thanks & Regards, >> Kamalesh Babulal. > > I'm mystified. I'm quite unable to reproduce this on my own setup: the > ENAMETOOLONG error reporting mechanism prevents me from even getting > near the above bug. > > Could you add a little printk into the 'encode_lookup' routine on line > 944 of fs/nfs/nfs4xdr.c to display the value of 'len'? > > Cheers > Trond Hi Trond, Sorry, for replying so late, i have included the printk as you have requested. len passed on encode_lookup [811]RESERVE_SPACE(819) failed in function encode_lookup Sep 24 13:20:02 p55lp2 kernel: ------------[ cut here ]------------ Sep 24 13:20:02 p55lp2 kernel: kernel BUG at fs/nfs/nfs4xdr.c:947! Sep 24 13:20:02 p55lp2 kernel: Oops: Exception in kernel mode, sig: 5 [#1] Sep 24 13:20:02 p55lp2 kernel: SMP NR_CPUS=128 NUMA pSeries Sep 24 13:20:02 p55lp2 kernel: Modules linked in: nfs lockd nfs_acl sunrpc ipv6 loop dm_mod ibmveth sg ibmvscsic sd_mod scsi_mod Sep 24 13:20:02 p55lp2 kernel: NIP: d000000000378228 LR: d000000000378218 CTR: 0000000000000001 Sep 24 13:20:02 p55lp2 kernel: REGS: c0000000e7daec50 TRAP: 0700 Not tainted (2.6.23-rc6-2-ppc64) Sep 24 13:20:02 p55lp2 kernel: MSR: 8000000000029032 <EE,ME,IR,DR> CR: 28022424 XER: 00000014 Sep 24 13:20:02 p55lp2 kernel: TASK = c000000004bc05c0[3446] 'touch' THREAD: c0000000e7dac000 CPU: 1 Sep 24 13:20:02 p55lp2 kernel: GPR00: 0000000000000001 c0000000e7daeed0 d0000000003bda08 0000000000000034 Sep 24 13:20:02 p55lp2 kernel: GPR04: 0000000000000001 0000000000000001 0000000000000000 c0000000005c8bb0 Sep 24 13:20:02 p55lp2 kernel: GPR08: 0000000000002e35 c000000000616540 c00000000071c510 c00000000071c508 Sep 24 13:20:02 p55lp2 kernel: GPR12: 00000000000186a0 c0000000005e4a80 0000000010020000 0000000010000000 Sep 24 13:20:02 p55lp2 kernel: GPR16: 0000000010000000 000000001000765c 0000000000000000 0000000010020000 Sep 24 13:20:02 p55lp2 kernel: GPR20: 0000000000000001 0000000010020000 0000000000000001 c0000000e7daf630 Sep 24 13:20:02 p55lp2 kernel: GPR24: d00000000034f524 c0000000e750f054 c0000000e7daf3d0 c0000000e5026ce0 Sep 24 13:20:02 p55lp2 kernel: GPR28: 0000000000000000 0000000022000000 d0000000003b9100 000000000000032b Sep 24 13:20:02 p55lp2 kernel: NIP [d000000000378228] .encode_lookup+0x84/0xd4 [nfs] Sep 24 13:20:02 p55lp2 kernel: LR [d000000000378218] .encode_lookup+0x74/0xd4 [nfs] Sep 24 13:20:02 p55lp2 kernel: Call Trace: Sep 24 13:20:02 p55lp2 kernel: [c0000000e7daeed0] [d000000000378218] .encode_lookup+0x74/0xd4 [nfs] (unreliable) Sep 24 13:20:02 p55lp2 kernel: [c0000000e7daef70] [d00000000037a170] .nfs4_xdr_enc_lookup+0x78/0xbc [nfs] Sep 24 13:20:02 p55lp2 kernel: [c0000000e7daf040] [d000000000314534] .rpcauth_wrap_req+0xe4/0x124 [sunrpc] Sep 24 13:20:02 p55lp2 kernel: [c0000000e7daf0f0] [d00000000030a790] .call_transmit+0x218/0x2b8 [sunrpc] Sep 24 13:20:02 p55lp2 kernel: [c0000000e7daf190] [d0000000003124d8] .__rpc_execute+0xd4/0x368 [sunrpc] Sep 24 13:20:02 p55lp2 kernel: [c0000000e7daf230] [d00000000030b114] .rpc_do_run_task+0xc8/0x104 [sunrpc] Sep 24 13:20:02 p55lp2 kernel: [c0000000e7daf2e0] [d00000000030b224] .rpc_call_sync+0x2c/0x64 [sunrpc] Sep 24 13:20:02 p55lp2 kernel: [c0000000e7daf360] [d00000000036f0c4] ._nfs4_proc_lookupfh+0xd4/0x124 [nfs] Sep 24 13:20:02 p55lp2 kernel: [c0000000e7daf450] [d000000000371b60] ._nfs4_proc_lookup+0x80/0x21c [nfs] Sep 24 13:20:02 p55lp2 kernel: [c0000000e7daf510] [d000000000371d64] .nfs4_proc_lookup+0x68/0xac [nfs] Sep 24 13:20:02 p55lp2 kernel: [c0000000e7daf5c0] [d000000000354c0c] .nfs_lookup+0x158/0x334 [nfs] Sep 24 13:20:02 p55lp2 kernel: [c0000000e7daf7c0] [c0000000000f3738] .do_lookup+0xfc/0x24c Sep 24 13:20:02 p55lp2 kernel: [c0000000e7daf880] [c0000000000f6c48] .__link_path_walk+0xce4/0x13b4 Sep 24 13:20:02 p55lp2 kernel: [c0000000e7daf960] [c0000000000f73b4] .link_path_walk+0x9c/0x184 Sep 24 13:20:02 p55lp2 kernel: [c0000000e7dafaa0] [c0000000000f7964] .do_path_lookup+0x2fc/0x3ac Sep 24 13:20:02 p55lp2 kernel: [c0000000e7dafb50] [c0000000000f83d4] .__user_walk_fd+0x58/0x88 Sep 24 13:20:02 p55lp2 kernel: [c0000000e7dafbf0] [c00000000011648c] .do_utimes+0x7c/0x24c Sep 24 13:20:02 p55lp2 kernel: [c0000000e7dafd70] [c00000000012a260] .compat_sys_futimesat+0x18c/0x1c4 Sep 24 13:20:02 p55lp2 kernel: [c0000000e7dafe30] [c000000000008534] syscall_exit+0x0/0x40 Sep 24 13:20:02 p55lp2 kernel: Instruction dump: Sep 24 13:20:02 p55lp2 kernel: e8410028 7fa4eb78 7c7c1b79 7fb80026 40820014 e8be83b0 e87e8350 4800c5fd Sep 24 13:20:02 p55lp2 kernel: e8410028 7fb80120 7c180026 54001ffe <0b000000> 3800000f 7be50020 387c0008 -- Thanks & Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [NFS] [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945 2007-09-24 19:01 ` Kamalesh Babulal @ 2007-09-24 21:26 ` Trond Myklebust 2007-09-28 12:05 ` Kamalesh Babulal 0 siblings, 1 reply; 14+ messages in thread From: Trond Myklebust @ 2007-09-24 21:26 UTC (permalink / raw) To: Kamalesh Babulal; +Cc: Michal Piotrowski, bfields, neilb, nfs, linux-kernel [-- Attachment #1: Type: text/plain, Size: 912 bytes --] On Tue, 2007-09-25 at 00:31 +0530, Kamalesh Babulal wrote: > > I'm mystified. I'm quite unable to reproduce this on my own setup: the > > ENAMETOOLONG error reporting mechanism prevents me from even getting > > near the above bug. > > > > Could you add a little printk into the 'encode_lookup' routine on line > > 944 of fs/nfs/nfs4xdr.c to display the value of 'len'? > > > > Cheers > > Trond > > Hi Trond, > > Sorry, for replying so late, i have included the printk as you have requested. > > len passed on encode_lookup [811]RESERVE_SPACE(819) failed in function encode_lookup OK. That is definitely wrong! We shouldn't be allowing anything > 255 according to <limits.h>. Looks like that code in fs/nfs/client.c has been wrong since its inception in 2.6.18. Not only for NFSv4, but for NFSv2 and v3 too. We only caught it 'cos v4 has more stringent tests... Take two on the patch attached... Trond [-- Attachment #2: linux-2.6.23-002-fix_nfs4_namelen.dif --] [-- Type: message/rfc822, Size: 4082 bytes --] From: Trond Myklebust <Trond.Myklebust@netapp.com> Subject: No Subject Date: Sun, 9 Sep 2007 00:10:51 +0200 Message-ID: <1190669172.6700.21.camel@heimdal.trondhjem.org> It doesn't look as if the NFS file name limit is being initialised correctly in the struct nfs_server. Make sure that we limit whatever is being set in nfs_probe_fsinfo() and nfs_init_server(). Also ensure that readdirplus and nfs4_path_walk respect our file name limits. Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> --- fs/nfs/client.c | 29 +++++++++++++++++++---------- fs/nfs/dir.c | 2 ++ fs/nfs/getroot.c | 3 +++ 3 files changed, 24 insertions(+), 10 deletions(-) diff --git a/fs/nfs/client.c b/fs/nfs/client.c index a49f9fe..a204484 100644 --- a/fs/nfs/client.c +++ b/fs/nfs/client.c @@ -588,16 +588,6 @@ static int nfs_init_server(struct nfs_server *server, const struct nfs_mount_dat server->namelen = data->namlen; /* Create a client RPC handle for the NFSv3 ACL management interface */ nfs_init_server_aclclient(server); - if (clp->cl_nfsversion == 3) { - if (server->namelen == 0 || server->namelen > NFS3_MAXNAMLEN) - server->namelen = NFS3_MAXNAMLEN; - if (!(data->flags & NFS_MOUNT_NORDIRPLUS)) - server->caps |= NFS_CAP_READDIRPLUS; - } else { - if (server->namelen == 0 || server->namelen > NFS2_MAXNAMLEN) - server->namelen = NFS2_MAXNAMLEN; - } - dprintk("<-- nfs_init_server() = 0 [new %p]\n", clp); return 0; @@ -794,6 +784,16 @@ struct nfs_server *nfs_create_server(const struct nfs_mount_data *data, error = nfs_probe_fsinfo(server, mntfh, &fattr); if (error < 0) goto error; + if (server->nfs_client->rpc_ops->version == 3) { + if (server->namelen == 0 || server->namelen > NFS3_MAXNAMLEN) + server->namelen = NFS3_MAXNAMLEN; + if (!(data->flags & NFS_MOUNT_NORDIRPLUS)) + server->caps |= NFS_CAP_READDIRPLUS; + } else { + if (server->namelen == 0 || server->namelen > NFS2_MAXNAMLEN) + server->namelen = NFS2_MAXNAMLEN; + } + if (!(fattr.valid & NFS_ATTR_FATTR)) { error = server->nfs_client->rpc_ops->getattr(server, mntfh, &fattr); if (error < 0) { @@ -984,6 +984,9 @@ struct nfs_server *nfs4_create_server(const struct nfs4_mount_data *data, if (error < 0) goto error; + if (server->namelen == 0 || server->namelen > NFS4_MAXNAMLEN) + server->namelen = NFS4_MAXNAMLEN; + BUG_ON(!server->nfs_client); BUG_ON(!server->nfs_client->rpc_ops); BUG_ON(!server->nfs_client->rpc_ops->file_inode_ops); @@ -1056,6 +1059,9 @@ struct nfs_server *nfs4_create_referral_server(struct nfs_clone_mount *data, if (error < 0) goto error; + if (server->namelen == 0 || server->namelen > NFS4_MAXNAMLEN) + server->namelen = NFS4_MAXNAMLEN; + dprintk("Referral FSID: %llx:%llx\n", (unsigned long long) server->fsid.major, (unsigned long long) server->fsid.minor); @@ -1115,6 +1121,9 @@ struct nfs_server *nfs_clone_server(struct nfs_server *source, if (error < 0) goto out_free_server; + if (server->namelen == 0 || server->namelen > NFS4_MAXNAMLEN) + server->namelen = NFS4_MAXNAMLEN; + dprintk("Cloned FSID: %llx:%llx\n", (unsigned long long) server->fsid.major, (unsigned long long) server->fsid.minor); diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c index ea97408..e4a04d1 100644 --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -1162,6 +1162,8 @@ static struct dentry *nfs_readdir_lookup(nfs_readdir_descriptor_t *desc) } if (!desc->plus || !(entry->fattr->valid & NFS_ATTR_FATTR)) return NULL; + if (name.len > NFS_SERVER(dir)->namelen) + return NULL; /* Note: caller is already holding the dir->i_mutex! */ dentry = d_alloc(parent, &name); if (dentry == NULL) diff --git a/fs/nfs/getroot.c b/fs/nfs/getroot.c index d1cbf0a..522e5ad 100644 --- a/fs/nfs/getroot.c +++ b/fs/nfs/getroot.c @@ -175,6 +175,9 @@ next_component: path++; name.len = path - (const char *) name.name; + if (name.len > NFS4_MAXNAMLEN) + return -ENAMETOOLONG; + eat_dot_dir: while (*path == '/') path++; ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [NFS] [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945 2007-09-24 21:26 ` Trond Myklebust @ 2007-09-28 12:05 ` Kamalesh Babulal 0 siblings, 0 replies; 14+ messages in thread From: Kamalesh Babulal @ 2007-09-28 12:05 UTC (permalink / raw) To: Trond Myklebust; +Cc: Michal Piotrowski, bfields, neilb, nfs, linux-kernel Trond Myklebust wrote: > On Tue, 2007-09-25 at 00:31 +0530, Kamalesh Babulal wrote: >>> I'm mystified. I'm quite unable to reproduce this on my own setup: the >>> ENAMETOOLONG error reporting mechanism prevents me from even getting >>> near the above bug. >>> >>> Could you add a little printk into the 'encode_lookup' routine on line >>> 944 of fs/nfs/nfs4xdr.c to display the value of 'len'? >>> >>> Cheers >>> Trond >> Hi Trond, >> >> Sorry, for replying so late, i have included the printk as you have requested. >> >> len passed on encode_lookup [811]RESERVE_SPACE(819) failed in function encode_lookup > > OK. That is definitely wrong! We shouldn't be allowing anything > 255 > according to <limits.h>. > > Looks like that code in fs/nfs/client.c has been wrong since its > inception in 2.6.18. Not only for NFSv4, but for NFSv2 and v3 too. We > only caught it 'cos v4 has more stringent tests... > > Take two on the patch attached... > > Trond > > > ------------------------------------------------------------------------ > > Subject: > No Subject > From: > Trond Myklebust <Trond.Myklebust@netapp.com> > Date: > Sun, 9 Sep 2007 00:10:51 +0200 > > > It doesn't look as if the NFS file name limit is being initialised correctly > in the struct nfs_server. Make sure that we limit whatever is being set in > nfs_probe_fsinfo() and nfs_init_server(). > > Also ensure that readdirplus and nfs4_path_walk respect our file name > limits. > > Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> > --- > > fs/nfs/client.c | 29 +++++++++++++++++++---------- > fs/nfs/dir.c | 2 ++ > fs/nfs/getroot.c | 3 +++ > 3 files changed, 24 insertions(+), 10 deletions(-) > > diff --git a/fs/nfs/client.c b/fs/nfs/client.c > index a49f9fe..a204484 100644 > --- a/fs/nfs/client.c > +++ b/fs/nfs/client.c > @@ -588,16 +588,6 @@ static int nfs_init_server(struct nfs_server *server, const struct nfs_mount_dat > server->namelen = data->namlen; > /* Create a client RPC handle for the NFSv3 ACL management interface */ > nfs_init_server_aclclient(server); > - if (clp->cl_nfsversion == 3) { > - if (server->namelen == 0 || server->namelen > NFS3_MAXNAMLEN) > - server->namelen = NFS3_MAXNAMLEN; > - if (!(data->flags & NFS_MOUNT_NORDIRPLUS)) > - server->caps |= NFS_CAP_READDIRPLUS; > - } else { > - if (server->namelen == 0 || server->namelen > NFS2_MAXNAMLEN) > - server->namelen = NFS2_MAXNAMLEN; > - } > - > dprintk("<-- nfs_init_server() = 0 [new %p]\n", clp); > return 0; > > @@ -794,6 +784,16 @@ struct nfs_server *nfs_create_server(const struct nfs_mount_data *data, > error = nfs_probe_fsinfo(server, mntfh, &fattr); > if (error < 0) > goto error; > + if (server->nfs_client->rpc_ops->version == 3) { > + if (server->namelen == 0 || server->namelen > NFS3_MAXNAMLEN) > + server->namelen = NFS3_MAXNAMLEN; > + if (!(data->flags & NFS_MOUNT_NORDIRPLUS)) > + server->caps |= NFS_CAP_READDIRPLUS; > + } else { > + if (server->namelen == 0 || server->namelen > NFS2_MAXNAMLEN) > + server->namelen = NFS2_MAXNAMLEN; > + } > + > if (!(fattr.valid & NFS_ATTR_FATTR)) { > error = server->nfs_client->rpc_ops->getattr(server, mntfh, &fattr); > if (error < 0) { > @@ -984,6 +984,9 @@ struct nfs_server *nfs4_create_server(const struct nfs4_mount_data *data, > if (error < 0) > goto error; > > + if (server->namelen == 0 || server->namelen > NFS4_MAXNAMLEN) > + server->namelen = NFS4_MAXNAMLEN; > + > BUG_ON(!server->nfs_client); > BUG_ON(!server->nfs_client->rpc_ops); > BUG_ON(!server->nfs_client->rpc_ops->file_inode_ops); > @@ -1056,6 +1059,9 @@ struct nfs_server *nfs4_create_referral_server(struct nfs_clone_mount *data, > if (error < 0) > goto error; > > + if (server->namelen == 0 || server->namelen > NFS4_MAXNAMLEN) > + server->namelen = NFS4_MAXNAMLEN; > + > dprintk("Referral FSID: %llx:%llx\n", > (unsigned long long) server->fsid.major, > (unsigned long long) server->fsid.minor); > @@ -1115,6 +1121,9 @@ struct nfs_server *nfs_clone_server(struct nfs_server *source, > if (error < 0) > goto out_free_server; > > + if (server->namelen == 0 || server->namelen > NFS4_MAXNAMLEN) > + server->namelen = NFS4_MAXNAMLEN; > + > dprintk("Cloned FSID: %llx:%llx\n", > (unsigned long long) server->fsid.major, > (unsigned long long) server->fsid.minor); > diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c > index ea97408..e4a04d1 100644 > --- a/fs/nfs/dir.c > +++ b/fs/nfs/dir.c > @@ -1162,6 +1162,8 @@ static struct dentry *nfs_readdir_lookup(nfs_readdir_descriptor_t *desc) > } > if (!desc->plus || !(entry->fattr->valid & NFS_ATTR_FATTR)) > return NULL; > + if (name.len > NFS_SERVER(dir)->namelen) > + return NULL; > /* Note: caller is already holding the dir->i_mutex! */ > dentry = d_alloc(parent, &name); > if (dentry == NULL) > diff --git a/fs/nfs/getroot.c b/fs/nfs/getroot.c > index d1cbf0a..522e5ad 100644 > --- a/fs/nfs/getroot.c > +++ b/fs/nfs/getroot.c > @@ -175,6 +175,9 @@ next_component: > path++; > name.len = path - (const char *) name.name; > > + if (name.len > NFS4_MAXNAMLEN) > + return -ENAMETOOLONG; > + > eat_dot_dir: > while (*path == '/') > path++; Hi Trond, Thanks, your patch fixes the bug. -- Thanks & Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945 2007-09-07 23:56 ` Michal Piotrowski 2007-09-08 22:12 ` [NFS] " Trond Myklebust @ 2007-09-10 12:56 ` Kamalesh Babulal 1 sibling, 0 replies; 14+ messages in thread From: Kamalesh Babulal @ 2007-09-10 12:56 UTC (permalink / raw) To: Michal Piotrowski; +Cc: linux-kernel, bfields, neilb, nfs Michal Piotrowski wrote: > Hi, > > On 07/09/2007, Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote: > >> Sep 7 11:42:49 p55lp2 kernel: kernel BUG at fs/nfs/nfs4xdr.c:945! >> Sep 7 11:42:49 p55lp2 kernel: Oops: Exception in kernel mode, sig: 5 [#1] >> Sep 7 11:42:49 p55lp2 kernel: SMP NR_CPUS=128 NUMA pSeries >> Sep 7 11:42:49 p55lp2 kernel: Modules linked in: nfs lockd nfs_acl >> sunrpc ipv6 loop dm_mod ibmveth sg ibmvscsic sd_mod scsi_mod >> Sep 7 11:42:49 p55lp2 kernel: NIP: d000000000378044 LR: >> d000000000378034 CTR: 80000000001c5840 >> Sep 7 11:42:49 p55lp2 kernel: REGS: c0000000d971b050 TRAP: 0700 Not >> tainted (2.6.23-rc5-ppc64) >> Sep 7 11:42:49 p55lp2 kernel: MSR: 8000000000029032 <EE,ME,IR,DR> CR: >> 28000444 XER: 00000014 >> Sep 7 11:42:49 p55lp2 kernel: TASK = c000000002787740[11508] 'fsstress' >> THREAD: c0000000d9718000 CPU: 1 >> Sep 7 11:42:49 p55lp2 kernel: GPR00: 0000000000000001 c0000000d971b2d0 >> d0000000003bd648 0000000000000037 >> Sep 7 11:42:49 p55lp2 kernel: GPR04: 0000000000000000 0000000000000000 >> 0000000000000000 0000000000000000 >> Sep 7 11:42:49 p55lp2 kernel: GPR08: 0000000000000002 c000000000616538 >> c0000000ef7afb58 c000000000616540 >> Sep 7 11:42:49 p55lp2 kernel: GPR12: 0000000000004000 c0000000005e4a80 >> 0000000000000000 00000000200b2510 >> Sep 7 11:42:49 p55lp2 kernel: GPR16: 0000000020105550 00000000200b2534 >> 000000002008c15c 0000000000000001 >> Sep 7 11:42:49 p55lp2 kernel: GPR20: 0000000000000000 0000000000000001 >> fffffffffffff000 c0000000d971ba30 >> Sep 7 11:42:49 p55lp2 kernel: GPR24: d00000000034f524 c0000000dc4f8054 >> c0000000d971b7d0 c0000000d9d313f0 >> Sep 7 11:42:49 p55lp2 kernel: GPR28: 0000000000000276 0000000022000000 >> d0000000003b8d78 0000000000000000 >> Sep 7 11:42:49 p55lp2 kernel: NIP [d000000000378044] >> .encode_lookup+0x6c/0xbc [nfs] >> Sep 7 11:42:49 p55lp2 kernel: LR [d000000000378034] >> .encode_lookup+0x5c/0xbc [nfs] >> Sep 7 11:42:49 p55lp2 kernel: Call Trace: >> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b2d0] [d000000000378034] >> .encode_lookup+0x5c/0xbc [nfs] (unreliable) >> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b370] [d000000000379f8c] >> .nfs4_xdr_enc_lookup+0x78/0xbc [nfs] >> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b440] [d000000000314534] >> .rpcauth_wrap_req+0xe4/0x124 [sunrpc] >> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b4f0] [d00000000030a790] >> .call_transmit+0x218/0x2b8 [sunrpc] >> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b590] [d0000000003124d8] >> .__rpc_execute+0xd4/0x368 [sunrpc] >> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b630] [d00000000030b114] >> .rpc_do_run_task+0xc8/0x104 [sunrpc] >> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b6e0] [d00000000030b224] >> .rpc_call_sync+0x2c/0x64 [sunrpc] >> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b760] [d00000000036ef04] >> ._nfs4_proc_lookupfh+0xd4/0x124 [nfs] >> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b850] [d0000000003719a0] >> ._nfs4_proc_lookup+0x80/0x21c [nfs] >> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b910] [d000000000371ba4] >> .nfs4_proc_lookup+0x68/0xac [nfs] >> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971b9c0] [d000000000354bf4] >> .nfs_lookup+0x158/0x334 [nfs] >> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971bbc0] [c0000000000f3a28] >> .lookup_hash+0xfc/0x140 >> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971bc60] [c0000000000f7b28] >> .sys_renameat+0x164/0x228 >> Sep 7 11:42:49 p55lp2 kernel: [c0000000d971be30] [c000000000008534] >> syscall_exit+0x0/0x40 >> Sep 7 11:42:49 p55lp2 kernel: Instruction dump: >> Sep 7 11:42:49 p55lp2 kernel: e8410028 7fa4eb78 7c7f1b79 7fb80026 >> 40820014 e8be83a8 e87e8350 4800c5f9 >> Sep 7 11:42:49 p55lp2 kernel: e8410028 7fb80120 7c180026 54001ffe >> <0b000000> 3800000f 7b850020 387f0008 >> > > Is this a post 2.6.22 regression? Have you tried 2.6.23-rc5-git1? > (There are a few nfs fixes) > > Regards, > Michal > When i tried with 2.6.23-rc5-git1, i dropped in xmon state with following trace cpu 0x1: Vector: 700 (Program Check) at [c0000000e28c30c0] pc: d000000000846d74: .nfs4_xdr_enc_create+0x204/0x2b4 [nfs] lr: d000000000846d68: .nfs4_xdr_enc_create+0x1f8/0x2b4 [nfs] sp: c0000000e28c3340 msr: 8000000000029032 current = 0xc0000000e58a4790 paca = 0xc0000000005eaf00 pid = 3452, comm = fsstress kernel BUG at fs/nfs/nfs4xdr.c:788! 1:mon> t [c0000000e28c3410] d00000000019a2d4 .rpcauth_wrap_req+0xe4/0x124 [sunrpc] [c0000000e28c34c0] d000000000190774 .call_transmit+0x218/0x2b8 [sunrpc] [c0000000e28c3560] d000000000198308 .__rpc_execute+0xd4/0x34c [sunrpc] [c0000000e28c3600] d0000000001910f8 .rpc_do_run_task+0xc8/0x104 [sunrpc] [c0000000e28c36b0] d000000000191208 .rpc_call_sync+0x2c/0x64 [sunrpc] [c0000000e28c3730] d00000000083bd68 .nfs4_proc_symlink+0x180/0x220 [nfs] [c0000000e28c3ae0] d000000000822298 .nfs_symlink+0x1b8/0x344 [nfs] [c0000000e28c3c60] c0000000000f5400 .vfs_symlink+0x144/0x1e8 [c0000000e28c3d00] c0000000000f8bf0 .sys_symlinkat+0xa8/0x110 [c0000000e28c3e30] c000000000008534 syscall_exit+0x0/0x40 --- Exception: c01 (System Call) at 000000000ff578c0 SP (ff9e59d0) is in userspace 1:mon> and i am not sure of the post 2.6.22 regression. Thanks & Regards, Kamalesh Babulal. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2007-09-28 12:06 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-09-07 10:02 [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945 Kamalesh Babulal 2007-09-07 15:29 ` J. Bruce Fields 2007-09-10 18:02 ` Kamalesh Babulal 2007-09-07 23:56 ` Michal Piotrowski 2007-09-08 22:12 ` [NFS] " Trond Myklebust 2007-09-10 8:11 ` suzuki 2007-09-10 21:03 ` Trond Myklebust 2007-09-11 4:56 ` suzuki 2007-09-10 13:06 ` Kamalesh Babulal 2007-09-19 17:31 ` Trond Myklebust 2007-09-24 19:01 ` Kamalesh Babulal 2007-09-24 21:26 ` Trond Myklebust 2007-09-28 12:05 ` Kamalesh Babulal 2007-09-10 12:56 ` Kamalesh Babulal
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox