On Wed, Aug 15, 2012 at 03:22:42AM -0700, Joel Becker wrote: > So, I think you are right that we can't be relying on it *that* > much, because splicing the alias doesn't clear it right away. In other > words, we rely on other mechanisms to ensure we have our lock attached > when the dentry is reachable, but if we're dropping an unreachable > dentry, we might not have the lock attached, and we need to detect that. > So your original point, that the code "can't be right", is > really that the code is overly permissive. If we have a reachable tree > with DISCONNECTED not yet cleared, that lock should be attached, but > this check won't catch it. That's fine. We rely on other code. > Conversely, we *know* we can get here with DISCONNECTED set from nfs or > d_kill, and we don't want to print errors for a sane state. OK, so we're depending on the DCACHE_DISCONNECTED check *only* to decide whether to warn, and you don't mind missing some warnings as long as you never warn when you shouldn't. Makes sense, thanks! --b. -- 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
