Re: [NFS] [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945

2007-09-28 Thread Kamalesh Babulal 
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 .
> 
> 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)

Re: [NFS] [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945

2007-09-24 Thread Trond Myklebust 
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 .

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
--- Begin Message ---
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 == NUL

Re: [NFS] [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945

2007-09-24 Thread Kamalesh Babulal 
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: d0378044 LR:
> d0378034 CTR: 801c5840
> Sep  7 11:42:49 p55lp2 kernel: REGS: c000d971b050 TRAP: 0700   Not
> tainted  (2.6.23-rc5-ppc64)
> Sep  7 11:42:49 p55lp2 kernel: MSR: 80029032   CR:
> 28000444  XER: 0014
> Sep  7 11:42:49 p55lp2 kernel: TASK = c2787740[11508] 'fsstress'
> THREAD: c000d9718000 CPU: 1
> Sep  7 11:42:49 p55lp2 kernel: GPR00: 0001 c000d971b2d0
> d03bd648 0037
> Sep  7 11:42:49 p55lp2 kernel: GPR04:  
>  
> Sep  7 11:42:49 p55lp2 kernel: GPR08: 0002 c0616538
> c000ef7afb58 c0616540
> Sep  7 11:42:49 p55lp2 kernel: GPR12: 4000 c05e4a80
>  200b2510
> Sep  7 11:42:49 p55lp2 kernel: GPR16: 20105550 200b2534
> 2008c15c 0001
> Sep  7 11:42:49 p55lp2 kernel: GPR20:  0001
> f000 c000d971ba30
> Sep  7 11:42:49 p55lp2 kernel: GPR24: d034f524 c000dc4f8054
> c000d971b7d0 c000d9d313f0
> Sep  7 11:42:49 p55lp2 kernel: GPR28: 0276 2200
> d03b8d78 
> Sep  7 11:42:49 p55lp2 kernel: NIP [d0378044]
> .encode_lookup+0x6c/0xbc [nfs]
> Sep  7 11:42:49 p55lp2 kernel: LR [d0378034]
> .encode_lookup+0x5c/0xbc [nfs]
> Sep  7 11:42:49 p55lp2 kernel: Call Trace:
> Sep  7 11:42:49 p55lp2 kernel: [c000d971b2d0] [d0378034]
> .encode_lookup+0x5c/0xbc [nfs] (unreliable)
> Sep  7 11:42:49 p55lp2 kernel: [c000d971b370] [d0379f8c]
> .nfs4_xdr_enc_lookup+0x78/0xbc [nfs]
> Sep  7 11:42:49 p55lp2 kernel: [c000d971b440] [d0314534]
> .rpcauth_wrap_req+0xe4/0x124 [sunrpc]
> Sep  7 11:42:49 p55lp2 kernel: [c000d971b4f0] [d030a790]
> .call_transmit+0x218/0x2b8 [sunrpc]
> Sep  7 11:42:49 p55lp2 kernel: [c000d971b590] [d03124d8]
> .__rpc_execute+0xd4/0x368 [sunrpc]
> Sep  7 11:42:49 p55lp2 kernel: [c000d971b630] [d030b114]
> .rpc_do_run_task+0xc8/0x104 [sunrpc]
> Sep  7 11:42:49 p55lp2 kernel: [c000d971b6e0] [d030b224]
> .rpc_call_sync+0x2c/0x64 [sunrpc]
> Sep  7 11:42:49 p55lp2 kernel: [c000d971b760] [d036ef04]
> ._nfs4_proc_lookupfh+0xd4/0x124 [nfs]
> Sep  7 11:42:49 p55lp2 kernel: [c000d971b850] [d03719a0]
> ._nfs4_proc_lookup+0x80/0x21c [nfs]
> Sep  7 11:42:49 p55lp2 kernel: [c000d971b910] [d0371ba4]
> .nfs4_proc_lookup+0x68/0xac [nfs]
> Sep  7 11:42:49 p55lp2 kernel: [c000d971b9c0] [d0354bf4]
> .nfs_lookup+0x158/0x334 [nfs]
> Sep  7 11:42:49 p55lp2 kernel: [c000d971bbc0] [c00f3a28]
> .lookup_hash+0xfc/0x140
> Sep  7 11:42:49 p55lp2 kernel: [c000d971bc60] [c00f7b28]
> .sys_renameat+0x164/0x228
> Sep  7 11:42:49 p55lp2 kernel: [c000d971be30] [c0008534]
> 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
> <0b00> 380f 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/clie

Re: [NFS] [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945

2007-09-19 Thread Trond Myklebust 
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: d0378044 LR:
> >>> d0378034 CTR: 801c5840
> >>> Sep  7 11:42:49 p55lp2 kernel: REGS: c000d971b050 TRAP: 0700   Not
> >>> tainted  (2.6.23-rc5-ppc64)
> >>> Sep  7 11:42:49 p55lp2 kernel: MSR: 80029032   CR:
> >>> 28000444  XER: 0014
> >>> Sep  7 11:42:49 p55lp2 kernel: TASK = c2787740[11508] 'fsstress'
> >>> THREAD: c000d9718000 CPU: 1
> >>> Sep  7 11:42:49 p55lp2 kernel: GPR00: 0001 c000d971b2d0
> >>> d03bd648 0037
> >>> Sep  7 11:42:49 p55lp2 kernel: GPR04:  
> >>>  
> >>> Sep  7 11:42:49 p55lp2 kernel: GPR08: 0002 c0616538
> >>> c000ef7afb58 c0616540
> >>> Sep  7 11:42:49 p55lp2 kernel: GPR12: 4000 c05e4a80
> >>>  200b2510
> >>> Sep  7 11:42:49 p55lp2 kernel: GPR16: 20105550 200b2534
> >>> 2008c15c 0001
> >>> Sep  7 11:42:49 p55lp2 kernel: GPR20:  0001
> >>> f000 c000d971ba30
> >>> Sep  7 11:42:49 p55lp2 kernel: GPR24: d034f524 c000dc4f8054
> >>> c000d971b7d0 c000d9d313f0
> >>> Sep  7 11:42:49 p55lp2 kernel: GPR28: 0276 2200
> >>> d03b8d78 
> >>> Sep  7 11:42:49 p55lp2 kernel: NIP [d0378044]
> >>> .encode_lookup+0x6c/0xbc [nfs]
> >>> Sep  7 11:42:49 p55lp2 kernel: LR [d0378034]
> >>> .encode_lookup+0x5c/0xbc [nfs]
> >>> Sep  7 11:42:49 p55lp2 kernel: Call Trace:
> >>> Sep  7 11:42:49 p55lp2 kernel: [c000d971b2d0] [d0378034]
> >>> .encode_lookup+0x5c/0xbc [nfs] (unreliable)
> >>> Sep  7 11:42:49 p55lp2 kernel: [c000d971b370] [d0379f8c]
> >>> .nfs4_xdr_enc_lookup+0x78/0xbc [nfs]
> >>> Sep  7 11:42:49 p55lp2 kernel: [c000d971b440] [d0314534]
> >>> .rpcauth_wrap_req+0xe4/0x124 [sunrpc]
> >>> Sep  7 11:42:49 p55lp2 kernel: [c000d971b4f0] [d030a790]
> >>> .call_transmit+0x218/0x2b8 [sunrpc]
> >>> Sep  7 11:42:49 p55lp2 kernel: [c000d971b590] [d03124d8]
> >>> .__rpc_execute+0xd4/0x368 [sunrpc]
> >>> Sep  7 11:42:49 p55lp2 kernel: [c000d971b630] [d030b114]
> >>> .rpc_do_run_task+0xc8/0x104 [sunrpc]
> >>> Sep  7 11:42:49 p55lp2 kernel: [c000d971b6e0] [d030b224]
> >>> .rpc_call_sync+0x2c/0x64 [sunrpc]
> >>> Sep  7 11:42:49 p55lp2 kernel: [c000d971b760] [d036ef04]
> >>> ._nfs4_proc_lookupfh+0xd4/0x124 [nfs]
> >>> Sep  7 11:42:49 p55lp2 kernel: [c000d971b850] [d03719a0]
> >>> ._nfs4_proc_lookup+0x80/0x21c [nfs]
> >>> Sep  7 11:42:49 p55lp2 kernel: [c000d971b910] [d0371ba4]
> >>> .nfs4_proc_lookup+0x68/0xac [nfs]
> >>> Sep  7 11:42:49 p55lp2 kernel: [c000d971b9c0] [d0354bf4]
> >>> .nfs_lookup+0x158/0x334 [nfs]
> >>> Sep  7 11:42:49 p55lp2 kernel: [c000d971bbc0] [c00f3a28]
> >>> .lookup_hash+0xfc/0x140
> >>> Sep  7 11:42:49 p55lp2 kernel: [c000d971bc60] [c00f7b28]
> >>> .sys_renameat+0x164/0x228
> >>> Sep  7 11:42:49 p55lp2 kernel: [c000d971be30] [c0008534]
> >>> 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
> >>> <0b00> 380f 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

Re: [NFS] [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945

2007-09-10 Thread suzuki 

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



-
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/

Re: [NFS] [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945

2007-09-10 Thread Trond Myklebust 
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

-
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/

Re: [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945

2007-09-10 Thread Kamalesh Babulal 

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.
-
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/

Re: [NFS] [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945

2007-09-10 Thread Kamalesh Babulal 

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: d0378044 LR:
d0378034 CTR: 801c5840
Sep  7 11:42:49 p55lp2 kernel: REGS: c000d971b050 TRAP: 0700   Not
tainted  (2.6.23-rc5-ppc64)
Sep  7 11:42:49 p55lp2 kernel: MSR: 80029032   CR:
28000444  XER: 0014
Sep  7 11:42:49 p55lp2 kernel: TASK = c2787740[11508] 'fsstress'
THREAD: c000d9718000 CPU: 1
Sep  7 11:42:49 p55lp2 kernel: GPR00: 0001 c000d971b2d0
d03bd648 0037
Sep  7 11:42:49 p55lp2 kernel: GPR04:  
 
Sep  7 11:42:49 p55lp2 kernel: GPR08: 0002 c0616538
c000ef7afb58 c0616540
Sep  7 11:42:49 p55lp2 kernel: GPR12: 4000 c05e4a80
 200b2510
Sep  7 11:42:49 p55lp2 kernel: GPR16: 20105550 200b2534
2008c15c 0001
Sep  7 11:42:49 p55lp2 kernel: GPR20:  0001
f000 c000d971ba30
Sep  7 11:42:49 p55lp2 kernel: GPR24: d034f524 c000dc4f8054
c000d971b7d0 c000d9d313f0
Sep  7 11:42:49 p55lp2 kernel: GPR28: 0276 2200
d03b8d78 
Sep  7 11:42:49 p55lp2 kernel: NIP [d0378044]
.encode_lookup+0x6c/0xbc [nfs]
Sep  7 11:42:49 p55lp2 kernel: LR [d0378034]
.encode_lookup+0x5c/0xbc [nfs]
Sep  7 11:42:49 p55lp2 kernel: Call Trace:
Sep  7 11:42:49 p55lp2 kernel: [c000d971b2d0] [d0378034]
.encode_lookup+0x5c/0xbc [nfs] (unreliable)
Sep  7 11:42:49 p55lp2 kernel: [c000d971b370] [d0379f8c]
.nfs4_xdr_enc_lookup+0x78/0xbc [nfs]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b440] [d0314534]
.rpcauth_wrap_req+0xe4/0x124 [sunrpc]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b4f0] [d030a790]
.call_transmit+0x218/0x2b8 [sunrpc]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b590] [d03124d8]
.__rpc_execute+0xd4/0x368 [sunrpc]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b630] [d030b114]
.rpc_do_run_task+0xc8/0x104 [sunrpc]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b6e0] [d030b224]
.rpc_call_sync+0x2c/0x64 [sunrpc]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b760] [d036ef04]
._nfs4_proc_lookupfh+0xd4/0x124 [nfs]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b850] [d03719a0]
._nfs4_proc_lookup+0x80/0x21c [nfs]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b910] [d0371ba4]
.nfs4_proc_lookup+0x68/0xac [nfs]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b9c0] [d0354bf4]
.nfs_lookup+0x158/0x334 [nfs]
Sep  7 11:42:49 p55lp2 kernel: [c000d971bbc0] [c00f3a28]
.lookup_hash+0xfc/0x140
Sep  7 11:42:49 p55lp2 kernel: [c000d971bc60] [c00f7b28]
.sys_renameat+0x164/0x228
Sep  7 11:42:49 p55lp2 kernel: [c000d971be30] [c0008534]
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
<0b00> 380f 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 [c000e2d5f050]
   pc: d0841668: .encode_lookup+0x6c/0xbc [nfs]
   lr: d

Re: [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945

2007-09-10 Thread Kamalesh Babulal 

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: d0378044 LR:
d0378034 CTR: 801c5840
Sep  7 11:42:49 p55lp2 kernel: REGS: c000d971b050 TRAP: 0700   Not
tainted  (2.6.23-rc5-ppc64)
Sep  7 11:42:49 p55lp2 kernel: MSR: 80029032   CR:
28000444  XER: 0014
Sep  7 11:42:49 p55lp2 kernel: TASK = c2787740[11508] 'fsstress'
THREAD: c000d9718000 CPU: 1
Sep  7 11:42:49 p55lp2 kernel: GPR00: 0001 c000d971b2d0
d03bd648 0037
Sep  7 11:42:49 p55lp2 kernel: GPR04:  
 
Sep  7 11:42:49 p55lp2 kernel: GPR08: 0002 c0616538
c000ef7afb58 c0616540
Sep  7 11:42:49 p55lp2 kernel: GPR12: 4000 c05e4a80
 200b2510
Sep  7 11:42:49 p55lp2 kernel: GPR16: 20105550 200b2534
2008c15c 0001
Sep  7 11:42:49 p55lp2 kernel: GPR20:  0001
f000 c000d971ba30
Sep  7 11:42:49 p55lp2 kernel: GPR24: d034f524 c000dc4f8054
c000d971b7d0 c000d9d313f0
Sep  7 11:42:49 p55lp2 kernel: GPR28: 0276 2200
d03b8d78 
Sep  7 11:42:49 p55lp2 kernel: NIP [d0378044]
.encode_lookup+0x6c/0xbc [nfs]
Sep  7 11:42:49 p55lp2 kernel: LR [d0378034]
.encode_lookup+0x5c/0xbc [nfs]
Sep  7 11:42:49 p55lp2 kernel: Call Trace:
Sep  7 11:42:49 p55lp2 kernel: [c000d971b2d0] [d0378034]
.encode_lookup+0x5c/0xbc [nfs] (unreliable)
Sep  7 11:42:49 p55lp2 kernel: [c000d971b370] [d0379f8c]
.nfs4_xdr_enc_lookup+0x78/0xbc [nfs]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b440] [d0314534]
.rpcauth_wrap_req+0xe4/0x124 [sunrpc]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b4f0] [d030a790]
.call_transmit+0x218/0x2b8 [sunrpc]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b590] [d03124d8]
.__rpc_execute+0xd4/0x368 [sunrpc]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b630] [d030b114]
.rpc_do_run_task+0xc8/0x104 [sunrpc]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b6e0] [d030b224]
.rpc_call_sync+0x2c/0x64 [sunrpc]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b760] [d036ef04]
._nfs4_proc_lookupfh+0xd4/0x124 [nfs]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b850] [d03719a0]
._nfs4_proc_lookup+0x80/0x21c [nfs]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b910] [d0371ba4]
.nfs4_proc_lookup+0x68/0xac [nfs]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b9c0] [d0354bf4]
.nfs_lookup+0x158/0x334 [nfs]
Sep  7 11:42:49 p55lp2 kernel: [c000d971bbc0] [c00f3a28]
.lookup_hash+0xfc/0x140
Sep  7 11:42:49 p55lp2 kernel: [c000d971bc60] [c00f7b28]
.sys_renameat+0x164/0x228
Sep  7 11:42:49 p55lp2 kernel: [c000d971be30] [c0008534]
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
<0b00> 380f 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 [c000e28c30c0]
pc: d0846d74: .nfs4_xdr_enc_create+0x204/0x2b4 [nfs]
lr: d0846d68: .nfs4_xdr_enc_create+0x1f8/0x2b4 [nfs]
sp: c000e28c3340
msr: 80029032
current = 0xc000e58a4790
paca = 0xc05eaf00
pid = 3452, comm = fsstress
kernel BUG at fs/nfs/nfs4xdr.c:788!
1:mon> t
[c000e28c3410] d019a2d4 .rpcauth_wrap_req+0xe4/0x124 [sunrpc]
[c000e28c34c0] d0190774 .call_transmit+0x218/0x2b8 [sunrpc]
[c000e28c3560] d0198308 .__rpc_execute+0xd4/0x34c [sunrpc]
[c000e28c3600] d01910f8 .rpc_do_run_task+0xc8/0x104 [sunrpc]
[c000e28c36b0] d0191208 .rpc_call_sync+0x2c/0x64 [sunrpc]
[c000e28c3730] d083bd68 .nfs4_proc_symlink+0x180/0x220 [nfs]
[c000e28c3ae0] d0822298 .nfs_symlink+0x1b8/0x344 [nfs]
[c000e28c3c60] c00f5400 .vfs_symlink+0x144/0x1e8
[c000e28c3d00] c00f8bf0 .sys_symlinkat+0xa8/0x110
[c000e28c3e30] c0008534 syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 0ff578c0
SP (ff9e59d0) is in userspace
1:mon>


and i am not sure of the post 2.6.22 regression.

Thanks & Regards,
Kamalesh Babulal.
-
To unsubscribe from

Re: [NFS] [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945

2007-09-10 Thread suzuki 

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: d0378044 LR:
d0378034 CTR: 801c5840
Sep  7 11:42:49 p55lp2 kernel: REGS: c000d971b050 TRAP: 0700   Not
tainted  (2.6.23-rc5-ppc64)
Sep  7 11:42:49 p55lp2 kernel: MSR: 80029032   CR:
28000444  XER: 0014
Sep  7 11:42:49 p55lp2 kernel: TASK = c2787740[11508] 'fsstress'
THREAD: c000d9718000 CPU: 1
Sep  7 11:42:49 p55lp2 kernel: GPR00: 0001 c000d971b2d0
d03bd648 0037
Sep  7 11:42:49 p55lp2 kernel: GPR04:  
 
Sep  7 11:42:49 p55lp2 kernel: GPR08: 0002 c0616538
c000ef7afb58 c0616540
Sep  7 11:42:49 p55lp2 kernel: GPR12: 4000 c05e4a80
 200b2510
Sep  7 11:42:49 p55lp2 kernel: GPR16: 20105550 200b2534
2008c15c 0001
Sep  7 11:42:49 p55lp2 kernel: GPR20:  0001
f000 c000d971ba30
Sep  7 11:42:49 p55lp2 kernel: GPR24: d034f524 c000dc4f8054
c000d971b7d0 c000d9d313f0
Sep  7 11:42:49 p55lp2 kernel: GPR28: 0276 2200
d03b8d78 
Sep  7 11:42:49 p55lp2 kernel: NIP [d0378044]
.encode_lookup+0x6c/0xbc [nfs]
Sep  7 11:42:49 p55lp2 kernel: LR [d0378034]
.encode_lookup+0x5c/0xbc [nfs]
Sep  7 11:42:49 p55lp2 kernel: Call Trace:
Sep  7 11:42:49 p55lp2 kernel: [c000d971b2d0] [d0378034]
.encode_lookup+0x5c/0xbc [nfs] (unreliable)
Sep  7 11:42:49 p55lp2 kernel: [c000d971b370] [d0379f8c]
.nfs4_xdr_enc_lookup+0x78/0xbc [nfs]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b440] [d0314534]
.rpcauth_wrap_req+0xe4/0x124 [sunrpc]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b4f0] [d030a790]
.call_transmit+0x218/0x2b8 [sunrpc]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b590] [d03124d8]
.__rpc_execute+0xd4/0x368 [sunrpc]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b630] [d030b114]
.rpc_do_run_task+0xc8/0x104 [sunrpc]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b6e0] [d030b224]
.rpc_call_sync+0x2c/0x64 [sunrpc]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b760] [d036ef04]
._nfs4_proc_lookupfh+0xd4/0x124 [nfs]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b850] [d03719a0]
._nfs4_proc_lookup+0x80/0x21c [nfs]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b910] [d0371ba4]
.nfs4_proc_lookup+0x68/0xac [nfs]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b9c0] [d0354bf4]
.nfs_lookup+0x158/0x334 [nfs]
Sep  7 11:42:49 p55lp2 kernel: [c000d971bbc0] [c00f3a28]
.lookup_hash+0xfc/0x140
Sep  7 11:42:49 p55lp2 kernel: [c000d971bc60] [c00f7b28]
.sys_renameat+0x164/0x228
Sep  7 11:42:49 p55lp2 kernel: [c000d971be30] [c0008534]
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
<0b00> 380f 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 || ser

Re: [NFS] [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945

2007-09-08 Thread Trond Myklebust 
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: d0378044 LR:
> > d0378034 CTR: 801c5840
> > Sep  7 11:42:49 p55lp2 kernel: REGS: c000d971b050 TRAP: 0700   Not
> > tainted  (2.6.23-rc5-ppc64)
> > Sep  7 11:42:49 p55lp2 kernel: MSR: 80029032   CR:
> > 28000444  XER: 0014
> > Sep  7 11:42:49 p55lp2 kernel: TASK = c2787740[11508] 'fsstress'
> > THREAD: c000d9718000 CPU: 1
> > Sep  7 11:42:49 p55lp2 kernel: GPR00: 0001 c000d971b2d0
> > d03bd648 0037
> > Sep  7 11:42:49 p55lp2 kernel: GPR04:  
> >  
> > Sep  7 11:42:49 p55lp2 kernel: GPR08: 0002 c0616538
> > c000ef7afb58 c0616540
> > Sep  7 11:42:49 p55lp2 kernel: GPR12: 4000 c05e4a80
> >  200b2510
> > Sep  7 11:42:49 p55lp2 kernel: GPR16: 20105550 200b2534
> > 2008c15c 0001
> > Sep  7 11:42:49 p55lp2 kernel: GPR20:  0001
> > f000 c000d971ba30
> > Sep  7 11:42:49 p55lp2 kernel: GPR24: d034f524 c000dc4f8054
> > c000d971b7d0 c000d9d313f0
> > Sep  7 11:42:49 p55lp2 kernel: GPR28: 0276 2200
> > d03b8d78 
> > Sep  7 11:42:49 p55lp2 kernel: NIP [d0378044]
> > .encode_lookup+0x6c/0xbc [nfs]
> > Sep  7 11:42:49 p55lp2 kernel: LR [d0378034]
> > .encode_lookup+0x5c/0xbc [nfs]
> > Sep  7 11:42:49 p55lp2 kernel: Call Trace:
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971b2d0] [d0378034]
> > .encode_lookup+0x5c/0xbc [nfs] (unreliable)
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971b370] [d0379f8c]
> > .nfs4_xdr_enc_lookup+0x78/0xbc [nfs]
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971b440] [d0314534]
> > .rpcauth_wrap_req+0xe4/0x124 [sunrpc]
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971b4f0] [d030a790]
> > .call_transmit+0x218/0x2b8 [sunrpc]
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971b590] [d03124d8]
> > .__rpc_execute+0xd4/0x368 [sunrpc]
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971b630] [d030b114]
> > .rpc_do_run_task+0xc8/0x104 [sunrpc]
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971b6e0] [d030b224]
> > .rpc_call_sync+0x2c/0x64 [sunrpc]
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971b760] [d036ef04]
> > ._nfs4_proc_lookupfh+0xd4/0x124 [nfs]
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971b850] [d03719a0]
> > ._nfs4_proc_lookup+0x80/0x21c [nfs]
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971b910] [d0371ba4]
> > .nfs4_proc_lookup+0x68/0xac [nfs]
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971b9c0] [d0354bf4]
> > .nfs_lookup+0x158/0x334 [nfs]
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971bbc0] [c00f3a28]
> > .lookup_hash+0xfc/0x140
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971bc60] [c00f7b28]
> > .sys_renameat+0x164/0x228
> > Sep  7 11:42:49 p55lp2 kernel: [c000d971be30] [c0008534]
> > 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
> > <0b00> 380f 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


--- Begin Message ---
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;
--- End Message ---

Re: [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945

2007-09-07 Thread Michal Piotrowski 
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: d0378044 LR:
> d0378034 CTR: 801c5840
> Sep  7 11:42:49 p55lp2 kernel: REGS: c000d971b050 TRAP: 0700   Not
> tainted  (2.6.23-rc5-ppc64)
> Sep  7 11:42:49 p55lp2 kernel: MSR: 80029032   CR:
> 28000444  XER: 0014
> Sep  7 11:42:49 p55lp2 kernel: TASK = c2787740[11508] 'fsstress'
> THREAD: c000d9718000 CPU: 1
> Sep  7 11:42:49 p55lp2 kernel: GPR00: 0001 c000d971b2d0
> d03bd648 0037
> Sep  7 11:42:49 p55lp2 kernel: GPR04:  
>  
> Sep  7 11:42:49 p55lp2 kernel: GPR08: 0002 c0616538
> c000ef7afb58 c0616540
> Sep  7 11:42:49 p55lp2 kernel: GPR12: 4000 c05e4a80
>  200b2510
> Sep  7 11:42:49 p55lp2 kernel: GPR16: 20105550 200b2534
> 2008c15c 0001
> Sep  7 11:42:49 p55lp2 kernel: GPR20:  0001
> f000 c000d971ba30
> Sep  7 11:42:49 p55lp2 kernel: GPR24: d034f524 c000dc4f8054
> c000d971b7d0 c000d9d313f0
> Sep  7 11:42:49 p55lp2 kernel: GPR28: 0276 2200
> d03b8d78 
> Sep  7 11:42:49 p55lp2 kernel: NIP [d0378044]
> .encode_lookup+0x6c/0xbc [nfs]
> Sep  7 11:42:49 p55lp2 kernel: LR [d0378034]
> .encode_lookup+0x5c/0xbc [nfs]
> Sep  7 11:42:49 p55lp2 kernel: Call Trace:
> Sep  7 11:42:49 p55lp2 kernel: [c000d971b2d0] [d0378034]
> .encode_lookup+0x5c/0xbc [nfs] (unreliable)
> Sep  7 11:42:49 p55lp2 kernel: [c000d971b370] [d0379f8c]
> .nfs4_xdr_enc_lookup+0x78/0xbc [nfs]
> Sep  7 11:42:49 p55lp2 kernel: [c000d971b440] [d0314534]
> .rpcauth_wrap_req+0xe4/0x124 [sunrpc]
> Sep  7 11:42:49 p55lp2 kernel: [c000d971b4f0] [d030a790]
> .call_transmit+0x218/0x2b8 [sunrpc]
> Sep  7 11:42:49 p55lp2 kernel: [c000d971b590] [d03124d8]
> .__rpc_execute+0xd4/0x368 [sunrpc]
> Sep  7 11:42:49 p55lp2 kernel: [c000d971b630] [d030b114]
> .rpc_do_run_task+0xc8/0x104 [sunrpc]
> Sep  7 11:42:49 p55lp2 kernel: [c000d971b6e0] [d030b224]
> .rpc_call_sync+0x2c/0x64 [sunrpc]
> Sep  7 11:42:49 p55lp2 kernel: [c000d971b760] [d036ef04]
> ._nfs4_proc_lookupfh+0xd4/0x124 [nfs]
> Sep  7 11:42:49 p55lp2 kernel: [c000d971b850] [d03719a0]
> ._nfs4_proc_lookup+0x80/0x21c [nfs]
> Sep  7 11:42:49 p55lp2 kernel: [c000d971b910] [d0371ba4]
> .nfs4_proc_lookup+0x68/0xac [nfs]
> Sep  7 11:42:49 p55lp2 kernel: [c000d971b9c0] [d0354bf4]
> .nfs_lookup+0x158/0x334 [nfs]
> Sep  7 11:42:49 p55lp2 kernel: [c000d971bbc0] [c00f3a28]
> .lookup_hash+0xfc/0x140
> Sep  7 11:42:49 p55lp2 kernel: [c000d971bc60] [c00f7b28]
> .sys_renameat+0x164/0x228
> Sep  7 11:42:49 p55lp2 kernel: [c000d971be30] [c0008534]
> 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
> <0b00> 380f 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/
-
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/

Re: [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945

2007-09-07 Thread J. Bruce Fields 
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/

[BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945

2007-09-07 Thread Kamalesh Babulal 

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: d0378044 LR: 
d0378034 CTR: 801c5840
Sep  7 11:42:49 p55lp2 kernel: REGS: c000d971b050 TRAP: 0700   Not 
tainted  (2.6.23-rc5-ppc64)
Sep  7 11:42:49 p55lp2 kernel: MSR: 80029032   CR: 
28000444  XER: 0014
Sep  7 11:42:49 p55lp2 kernel: TASK = c2787740[11508] 'fsstress' 
THREAD: c000d9718000 CPU: 1
Sep  7 11:42:49 p55lp2 kernel: GPR00: 0001 c000d971b2d0 
d03bd648 0037  
Sep  7 11:42:49 p55lp2 kernel: GPR04:   
   
Sep  7 11:42:49 p55lp2 kernel: GPR08: 0002 c0616538 
c000ef7afb58 c0616540  
Sep  7 11:42:49 p55lp2 kernel: GPR12: 4000 c05e4a80 
 200b2510  
Sep  7 11:42:49 p55lp2 kernel: GPR16: 20105550 200b2534 
2008c15c 0001  
Sep  7 11:42:49 p55lp2 kernel: GPR20:  0001 
f000 c000d971ba30  
Sep  7 11:42:49 p55lp2 kernel: GPR24: d034f524 c000dc4f8054 
c000d971b7d0 c000d9d313f0  
Sep  7 11:42:49 p55lp2 kernel: GPR28: 0276 2200 
d03b8d78   
Sep  7 11:42:49 p55lp2 kernel: NIP [d0378044] 
.encode_lookup+0x6c/0xbc [nfs]
Sep  7 11:42:49 p55lp2 kernel: LR [d0378034] 
.encode_lookup+0x5c/0xbc [nfs]

Sep  7 11:42:49 p55lp2 kernel: Call Trace:
Sep  7 11:42:49 p55lp2 kernel: [c000d971b2d0] [d0378034] 
.encode_lookup+0x5c/0xbc [nfs] (unreliable)
Sep  7 11:42:49 p55lp2 kernel: [c000d971b370] [d0379f8c] 
.nfs4_xdr_enc_lookup+0x78/0xbc [nfs]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b440] [d0314534] 
.rpcauth_wrap_req+0xe4/0x124 [sunrpc]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b4f0] [d030a790] 
.call_transmit+0x218/0x2b8 [sunrpc]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b590] [d03124d8] 
.__rpc_execute+0xd4/0x368 [sunrpc]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b630] [d030b114] 
.rpc_do_run_task+0xc8/0x104 [sunrpc]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b6e0] [d030b224] 
.rpc_call_sync+0x2c/0x64 [sunrpc]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b760] [d036ef04] 
._nfs4_proc_lookupfh+0xd4/0x124 [nfs]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b850] [d03719a0] 
._nfs4_proc_lookup+0x80/0x21c [nfs]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b910] [d0371ba4] 
.nfs4_proc_lookup+0x68/0xac [nfs]
Sep  7 11:42:49 p55lp2 kernel: [c000d971b9c0] [d0354bf4] 
.nfs_lookup+0x158/0x334 [nfs]
Sep  7 11:42:49 p55lp2 kernel: [c000d971bbc0] [c00f3a28] 
.lookup_hash+0xfc/0x140
Sep  7 11:42:49 p55lp2 kernel: [c000d971bc60] [c00f7b28] 
.sys_renameat+0x164/0x228
Sep  7 11:42:49 p55lp2 kernel: [c000d971be30] [c0008534] 
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 
<0b00> 380f 7b850020 387f0008

-
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/