On Fri, 2007-01-05 at 17:01 +0100, Trond Myklebust wrote: > On Fri, 2007-01-05 at 10:00 -0500, Shaya Potter wrote: > > I'd agree with you (And even told the person the problem up front) > > except it's not oopsing on a lack of intent information, it's oopsing > > because nd is null and therefore can not access nd->mnt. > > > > > i.e. Let say I couldn't reconstruct nd perfectly (due to not knowing > > vfsmnt information), I could possible construct a fake nd with the > > proper intent information (i.e. very likely no intent information to be > > passed) and it would still oops. > > No. The nameidata structure is _mandatory_, as is the intent info. In > order to ensure POSIX correctness, the NFS client sometimes needs to > create submounts (when crossing a mountpoint on the server). If you > don't provide a proper nameidata structure, then that is impossible. ok, I guess what I don't understand is when are dentry->d_sb->s_root and nd->mnt->mnt_root not equivalent. I guess it would be "when crossing a mountpoint on the server", so I look at nfs_follow_mountpoint() and basically see that you create a new mountpoint and a new nd for that. And since superblock objects are only per "real" file system not per mount point, they will be different. I guess the question is, why shouldn't a dentry object know what vfsmount it belongs to is? Can it belong to multiple vfsmount objects? (Again, probably showing my igornance here). Basically, the question I'm trying to figure out, are a) why do intents and nd have to be so tightly wound together? b) why can't a dentry object know about vfsmount? - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
