Messages in this thread | | | Subject | Re: [RFC] atomic open(..., O_CREAT | ...) | From | Trond Myklebust <> | Date | Tue, 09 Aug 2005 17:11:30 -0400 |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |