On Thu, Apr 21, 2011 at 6:09 AM, David Howells <dhowells@xxxxxxxxxx> wrote: > Valerie Aurora <valerie.aurora@xxxxxxxxx> wrote: > >> That's never up to date, but I just fixed it. The branch you want is >> "ext2_cleanup". Any branch with "+" at the front is a mistake from >> trying to do a git push of a rebased branch. I deleted it. > > Okay, I've got that pulled up to Linus's head branch. I've mostly got the RCU > pathwalk and managed dentry stuff correctly entangled. Awesome, thanks! > However, I have a few questions: > > (1) Is it meant to be possible to unionmount over a mount tree rather than > just a single mount? I ask because do_lookup_union() calls > __follow_mount(). It's meant to allow mounting over a mount tree, as long as all the mounts are read-only. I don't recall the difference between __follow_mount() and follow_mount() at this moment, but that code may be left over from the time that we could only union mount a single mount. Think about it carefully though, and check my comments, and run the union mounts test suite - I got this wrong a few times and added a number of tests to make sure the mount point case is right. > (2) When you open a file that exists in the lower layer but not the top > layer, am I right in thinking that f_path points to the lower layer file? If the file is opened read-write, then it is copied up and the f_path points to the upper layer file. If the file is opened read-only, then it is not copied up and the f_path points to the lower layer file. So, yes, f_path points to the lower layer file. > (3) If I'm correct in (2), I presume something must intercept fchown() and > suchlike? There's a thread somewhere on this, hang on... http://kerneltrap.org/mailarchive/linux-fsdevel/2010/3/29/6897953/thread Basically, if you open the file read-write and do an fchown() on it, it works fine because the file is copied up on open. If you open the file read-only and fchown() it (yes, that's permitted) then in union mounts you will get EPERM or EBADF (don't recall which). Actually implementing this requires copy-up after open, which requires atomic update of the struct file pointer, which is ugly and painful and what we were trying to avoid in the first place. I discussed this with Al and Christoph and the consensus was along the lines of, "What? You can do that? POSIX is so stupid. Yes, we don't care if union mounts returns EPERM in this case that no one thinks should work anyway." If you can find a way to do this cleanly, hurray. Otherwise the current code works for fchown/fchmod/utimensat already in the open read-write case. > (4) I presume IS_DIR_UNIONED() only gives true on the upper layer (the one > that was mounted -o union)? Yes. It maybe should be renamed... Thanks, -VAL -- 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
