Nick Piggin:
> On Fri, Jan 14, 2011 at 1:03 AM, J. R. Okajima <[email protected]> wrot=
> e:
> > NFSD calls filesystem's ->d_revalidate() with the parameter nd =3D=3D NUL=
> L.
:::
> Ah, good catch.
>
> I'm going to change the d_revalidate API so it takes and inode and rcu-walk
> flag parameter to make it easier for filesystems to implement rcu-walk.
>
> That will take care of this NULL nd case.
While you might already know there are similar parts in fs/namei.c, I'd
like to write here just to make sure.
- nfsd calls lookup_one_len()
- lookup_one_len()
+ __lookup_hash() with nd=NULL
+ do_revalidate(dentry, nd)
or/and
+ d_alloc_and_lookup(base, name, nd)
- do_revalidate(dentry, nd)
+ status = d_revalidate(dentry, nd)
+ d_op->d_revalidate(dentry, nd) <-- previous mail pointed out
+ if (status < 0) {
if (!(nd->flags & LOOKUP_RCU)) <-- this also needs fixing
dput(dentry);
} else {
if (nameidata_dentry_drop_rcu_maybe(nd, dentry)) <-- and here
return ERR_PTR(-ECHILD);
}
And if ->d_revalidate() can return ECHILD when 'nd' is NULL,
then nameidata_dentry_drop_rcu() call in d_revalidate() needs fixing
too.
I don't think ->lookup(inode, dentry, nd) call in d_alloc_and_lookup()
is a problem since every FS which supports NFS-exporting never refer
'nd' already.
J. R. Okajima