On Mon, Mar 08, 2010 at 10:10:14AM +1100, Neil Brown wrote: > On Sun, 7 Mar 2010 16:58:26 -0500 > "J. Bruce Fields" <bfields@xxxxxxxxxxxxxx> wrote: > > Don't we have this problem already, then? The export cache really is > > just a cache, and we should be prepared for a given entry to be purged > > at any time. > > > > Yes, it is a cache, but things don't get pushed out when it is 'full', so you > can expect items to stay out their expiry time. At least for some caches we may want some sort of pruning when they get to full. If we do that, then we may want to vary the behavior from cache to cache, hence keeping the export cache protected from this deadlock. Though I'd rather avoid that kind of special case if we could. > So if you add something > with an expiry 30 minutes in the future, you can usually expect it to still > be there in 30 seconds. > > If someone ran "exportfs -f" or "exportfs -r"? > at exactly the wrong time you might be able to deadlock mountd (I'd > have to double-check to be sure), but that is very different from > mountd acting in a way which leads directly to a deadlock. Yeah, agreed. It's still a bug--people are supposed to be able to do that without deadlock--but, sure, it may be unbelievably hard to hit. So, I need to look harder at this, thanks for the review. (May take a few days, though, so if someone else wants to volunteer, feel free.) I wonder how best to eliminate the deadlock: - Allow fh downcall to return -EAGAIN, let mountd change that to a JUKEBOX or dropped rpc? - Require mountd run two processes, with one dedicated to upcalls? - Separate mountd entirely into an upcall-handling daemon and an rpc daemon? Occasionally we seem to hear from a security-conscious administrator who's running v4-only and is irritated that they have to firewall off mountd instead of just being able to kill it entirely. The latter might reassure them, I suppose. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
