[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1190669172.6700.20.camel@heimdal.trondhjem.org>
Date: Mon, 24 Sep 2007 17:26:12 -0400
From: Trond Myklebust <trond.myklebust@....uio.no>
To: Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>
Cc: Michal Piotrowski <michal.k.k.piotrowski@...il.com>,
bfields@...ldses.org, neilb@...e.de, nfs@...ts.sourceforge.net,
linux-kernel@...r.kernel.org
Subject: Re: [NFS] [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945
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
Download attachment "linux-2.6.23-002-fix_nfs4_namelen.dif" of type "message/rfc822" (4083 bytes)
Powered by blists - more mailing lists