> > > There is quite a bit of code out there that assumes it is free to stuff
> > > things into nd->mnt and nd->dentry. Some of it is Al Viro's code, some
> > > of it is from other people.
> > > For instance, the ESTALE handling will just save nd->mnt/nd->dentry
> > > before calling __link_path_walk(), then restore + retry if the ESTALE
> > > error comes up.
> >
> > Yeah, but how is that relevant to the fact, that after
> > path_release_*() _nothing_ will be valid in the nameidata, not
> > nd->mnt, not nd->dentry, and not nd->intent.open.file. So what's the
> > point in setting it to NULL if it must never be used anyway?
>
> path_release() does _not_ invalidate the nameidata. Look for instance at
> __emul_lookup_dentry(), which clearly makes use of that fact.
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.
> 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.
Or you could initialize nameidata from filp_open().
Miklos
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |