> > > 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/