ty den 09.08.2005 Klokka 22:42 (+0200) skreiv Miklos Szeredi:
> Trond, wake up! __emul_lookup_dentry() does nothing of the sort.
> Neither does anything else. In theory it could, but that's not a
> reason to do a confusing thing like that.
Really?
static int __emul_lookup_dentry(const char *name, struct nameidata *nd)
{
.....
if (path_walk(name, nd) == 0) {
if (nd->dentry->d_inode) {
dput(old_dentry);
mntput(old_mnt);
return 1;
}
path_release(nd);
}
nd->dentry = old_dentry;
nd->mnt = old_mnt;
nd->last = last;
nd->last_type = last_type;
}
return 1;
}
Which is called by path_lookup(), which again returns success, and
expects the user to call path_release() later.
> > Firstly, the open_namei() flags field is not a "permissions" field. It
> > contains open mode information. The calculation of the open permissions
> > flags is done by open_namei() itself.
>
> Based on flags. It's just a FMODE_* -> MAY_* transformation
>
> > Secondly, what advantage is there in allowing callers of open_namei() to
> > be able to override the MAY_WRITE check when doing open(O_TRUNC)? This
> > is a calculation that should be done _once_ in order to always get it
> > right, and it should therefore be done in open_namei() together with the
> > rest of the permissions calculation.
>
> I think the _only_ caller of open_namei() is filp_open(), so this is
> not much of an issue, but yeah, you could do it that way too.
Currently, yes. The only caller of open_namei() is filp_open(). That was
not always the case previously.
If we think it will never be the case in the future, then there is an
argument for merging the two and/or making open_namei() and inlined
function.
Cheers,
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/
