On Wed, 2012-08-15 at 15:40 +0200, Richard Ems wrote:
> On 08/15/2012 03:38 PM, Myklebust, Trond wrote:
> > On Wed, 2012-08-15 at 15:22 +0200, Richard Ems wrote:
> >> On 08/15/2012 03:20 PM, Myklebust, Trond wrote:
> >>>> (gdb) list *(nfs_lookup_revalidate+0x2d)
> >>>> 0x59cd is in nfs_lookup_revalidate (/usr/src/debug/kernel-default-3.5.1/linux-3.5/fs/nfs/dir.c:1129).
> >>>> 1124 struct dentry *parent;
> >>>> 1125 struct nfs_fh *fhandle = NULL;
> >>>> 1126 struct nfs_fattr *fattr = NULL;
> >>>> 1127 int error;
> >>>> 1128
> >>>> 1129 if (nd->flags & LOOKUP_RCU)
> >>>
> >>> Bummer... We check if 'nd' is NULL everywhere except here...
> >>>
> >>> OK. Changing the above line to
> >>>
> >>> if (nd && (nd->flags & LOOKUP_RCU))
> >>>
> >>> will fix the problem.
> >>
> >> Ok, great !
> >> Do you think this fix will go into 3.5.2 ?
> >
> > I'll try to get it into stable. 3.6-rcX is unaffected by the bug due to
> > recent VFS changes that have removed the "struct nameidata *" argument
> > to nfs_lookup_revalidate.
> >
>
> Ok, many thanks. I have found a couple of other accesses to nd with no
> check for NULL at *nfs_atomic_lookup and nfs4_lookup_revalidate, but
> don't know if those are relevant.
It is relevant for nfs_open_revalidate(<=3.4) and
nfs4_lookup_revalidate(3.5), but not for nfs_atomic_lookup.
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
