On Mon, Jul 11, 2016 at 07:03:31AM -0400, Jeff Layton wrote: > On Mon, 2016-07-11 at 09:23 +0200, Michal Hocko wrote: > > On Fri 08-07-16 10:27:38, Jeff Layton wrote: > > > On Fri, 2016-07-08 at 16:23 +0200, Michal Hocko wrote: > > > > On Fri 08-07-16 08:51:54, Jeff Layton wrote: > > > > > > > > > > On Fri, 2016-07-08 at 14:22 +0200, Michal Hocko wrote: > > > > [...] > > > > > > > > > > > > > > > > > Apart from alternative Dave was mentioning in other email, what > > > > > > is the > > > > > > point to use freezable wait from this path in the first place? > > > > > > > > > > > > nfs4_handle_exception does nfs4_wait_clnt_recover from the same > > > > > > path and > > > > > > that does wait_on_bit_action with TASK_KILLABLE so we are waiting > > > > > > in two > > > > > > different modes from the same path AFAICS. There do not seem to > > > > > > be other > > > > > > callers of nfs4_delay outside of nfs4_handle_exception. Sounds > > > > > > like > > > > > > something is not quite right here to me. If the nfs4_delay did > > > > > > regular > > > > > > wait then the freezing would fail as well but at least it would > > > > > > be clear > > > > > > who is the culrprit rather than having an indirect dependency. > > > > > The codepaths involved there are a lot more complex than that > > > > > unfortunately. > > > > > > > > > > nfs4_delay is the function that we use to handle the case where the > > > > > server returns NFS4ERR_DELAY. Basically telling us that it's too > > > > > busy > > > > > right now or has some transient error and the client should retry > > > > > after > > > > > a small, sliding delay. > > > > > > > > > > That codepath could probably be made more freezer-safe. The typical > > > > > case however, is that we've sent a call and just haven't gotten a > > > > > reply. That's the trickier one to handle. > > > > Why using a regular non-freezable wait would be a problem? > > > > > > It has been a while since I looked at that code, but IIRC, that could > > > block the freezer for up to 15s, which is a significant portion of the > > > 20s that you get before the freezer gives up. > > > > But how does that differ from the situation when the freezer has to give > > up on the timeout because another task fails due to lock dependency. > > > > As Trond and Dave have written in other emails. It is really danngerous > > to freeze a task while it is holding locks and other resources. > > It's not really dangerous if you're freezing every task on the host. > Sure, you're freezing with locks held, but everything else is freezing > too, so nothing will be contending for those locks. Unless you have tasks either already waiting on those locks or that will attaempt to lock them before calling try_to_freeze. That happens to be the case in this cgroup freezer hang too, all the tasks stuck waiting on the i_mutex are p being frozen. > I'm not at all opposed to changing how all of that works. My only > stipulation is that we not break the ability to reliably suspend a host > that is actively using an NFS mount. If you can come up with a way to > do that that also works for freezing cgroups, then I'm all for it. The deadlock that we've seen should apply equally to suspend and to the cgroup freezer. The only difference is that suspend will eventually time out and abort the suspend whereas the cgroup freezer does not. Seth -- 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
