On Sun, Nov 30, 2008 at 09:15:52AM -0500, Steve Grubb wrote: You do realize that they are, in the end, done from userland? Which is the natural place to do that...

On Sun, Nov 30, 2008 at 10:47:07AM -0500, Steve Grubb wrote: Races are not hard to deal with - you mount on temporary directory, mark equivalent and mount --move to final destination. autofs daemon could do that just fine. As for the "anytime mount is called"... What are you going to do with the rules that *do* resolve to destination (subtree ones)? And to deal with the same races you'd have to do highly unpleasant things. In principle, it is possible. We hold i_mutex on the mountpoint and there is a moment just before grabbing vfsmount_lock when we know that we won't be backing off. That's when we are about to make the changes visible and locking conditions at that point are not quite unbearably bad. They *are* quite bad, though. There are three parts of that fun: * audit_filter_mutex needs to be held. Not a problem. * ->inotify_mutex is taken inside ->i_mutex that way. Not a problem, we already have that situation. * the real bitch: we really, REALLY can not do pathname resolution of any kind while we are in that area. kern_path() is a non-starter. That's where the PITA starts. Initial part is simple - we already know where and what we are going to attach, so unlike the case of MAKE_EQUIV handling we do not need to bother resolving those pathnames. However, the rest sucks hard enough to excavate decency from a politician. We need to decide which rules to extend. And doing _that_ accurately takes pathname resolution. Without it... well, the best proxy would be to see which rules cover a counterpart of mountpoint in some mounted instance of filesystem containing. Translation: we'll be getting false positives until audit_trim_trees() could be run. And we *can't* run it synchronously until we at least drop namespace_sem.