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
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 <[email protected]>
> 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 <[email protected]>
> ---
>
> 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.
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 <[email protected]> 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 <[email protected]>
>>> 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 <[email protected]>
>>> ---
>>>
>>> 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.
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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 <[email protected]> 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 <[email protected]>
> > 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 <[email protected]>
> > ---
> >
> > 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
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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 [email protected]
> 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.
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
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
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Hi,
On 07/09/2007, Kamalesh Babulal <[email protected]> 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/
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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 <[email protected]> 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 <[email protected]>
> 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 <[email protected]>
> ---
>
> 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;
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Michal Piotrowski wrote:
> Hi,
>
> On 07/09/2007, Kamalesh Babulal <[email protected]> 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.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Trond Myklebust wrote:
> On Sat, 2007-09-08 at 01:56 +0200, Michal Piotrowski wrote:
>
>> Hi,
>>
>> On 07/09/2007, Kamalesh Babulal <[email protected]> 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 <[email protected]>
> 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 <[email protected]>
> ---
>
> 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.