On Sat, Jan 15, 2011 at 5:06 AM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > On Fri, Jan 14, 2011 at 05:56:48PM +0000, Al Viro wrote: >> BTW, speaking of mntput_long(): I really hate that API. It's >> asking for subtle leaks - use mntget_long() in pair with mntput() and >> you are fucked. Worse, these suckers are created with long reference >> now, so any code that used to use mntput() to kill a cloned/freshly >> created vfsmount got silently b0rken. A quick look already caught >> one such case - fs/nfsctl.c do_open() uses mntput() in pair with >> do_kern_mount(), which leads to longrefs left at 1. Hmm ok. I agree it's not the nicest scheme. >> >> Rationale for that mess, please... > > FWIW, what I intend to do is to keep these longrefs _only_ for > cwd/root/attached or possibly hashed and set them alongside the > normal ref. I.e. require the callers of mntput_long() (not exported, > local to core VFS) to keep the normal reference. OK that sounds better... I didn't have a good rationale beyond those cases. > That way it would turn into hint for mntput() - "we have persistent > refs, just decrement count on this CPU and piss off", with mntput_long() > never going into the whole "and now we are dropping the last ref" part. I don't see the point of that, though. That's what it essentially already is, but the check is done by mntput rather than the caller passing it in as a hint. > AFAICS, it keeps your write-free objectives and gets much saner API. > Shout if you have problems with that... No that sounds good, I don't have a problem with it, although I don't exactly understand what you're getting at in the second paragraph. -- 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
