Return-Path: linux-nfs-owner@vger.kernel.org Received: from mx1.redhat.com ([209.132.183.28]:11120 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752951Ab3CEXj5 (ORCPT ); Tue, 5 Mar 2013 18:39:57 -0500 Date: Tue, 5 Mar 2013 18:39:41 -0500 From: Jeff Layton To: Tejun Heo Cc: "Myklebust, Trond" , Oleg Nesterov , Mandeep Singh Baines , Ming Lei , "J. Bruce Fields" , Linux Kernel Mailing List , "linux-nfs@vger.kernel.org" , "Rafael J. Wysocki" , Andrew Morton , Ingo Molnar , Al Viro Subject: Re: LOCKDEP: 3.9-rc1: mount.nfs/4272 still has locks held! Message-ID: <20130305183941.19ff39ce@tlielax.poochiereds.net> In-Reply-To: <20130305190923.GI12795@htj.dyndns.org> References: <4FA345DA4F4AE44899BD2B03EEEC2FA9286AD113@sacexcmbx05-prd.hq.netapp.com> <20130304092310.1d21100c@tlielax.poochiereds.net> <20130304205307.GA13527@redhat.com> <4FA345DA4F4AE44899BD2B03EEEC2FA9286AEEB0@sacexcmbx05-prd.hq.netapp.com> <20130305082308.6607d4db@tlielax.poochiereds.net> <20130305174648.GF12795@htj.dyndns.org> <20130305174954.GG12795@htj.dyndns.org> <20130305140312.243cb094@tlielax.poochiereds.net> <20130305190923.GI12795@htj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-nfs-owner@vger.kernel.org List-ID: On Tue, 5 Mar 2013 11:09:23 -0800 Tejun Heo wrote: > Hello, Jeff. > > On Tue, Mar 05, 2013 at 02:03:12PM -0500, Jeff Layton wrote: > > Sounds intriguing... > > > > I'm not sure what this really means for something like NFS though. How > > would you envision this working when we have long running syscalls that > > might sit waiting in the kernel indefinitely? > > I think it is the same problem as being able to handle SIGKILL in > responsive manner. It could be tricky to implement for nfs but it at > least doesn't have to solve the problem twice. > > > Here's my blue-sky, poorly-thought-out idea... > > > > We could add a signal (e.g. SIGFREEZE) that allows the sleeps in > > NFS/RPC layer to be interrupted. Those would return back toward > > userland with a particular type of error (sort of like ERESTARTSYS). > > > > Before returning from the kernel though, we could freeze the process. > > When it wakes up, then we could go back down and retry the call again > > (much like an ERESTARTSYS kind of thing). > > > > The tricky part here is that we'd need to distinguish between the case > > where we caught SIGFREEZE before sending an RPC vs. after. If we sent > > the call before freezing, then we don't want to resend it again. It > > might be a non-idempotent operation. > > So, yeah, you are thinking pretty much the same as I'm. > > > Sounds horrific to code up though... :) > > I don't know the details of nfs but those events could essentially be > signaling that the system is gonna lose power. I think it would be a > good idea to solve it. > > Thanks. > It would be... So, I briefly considered a similar approach when I was working on the retry-on-ESTALE error patches. It occurred to me that it was somewhat similar to the ERESTARTSYS case, so handling it at a higher level than in the syscall handlers themselves might make sense... Al was in the middle of his signal handling/execve rework though and I ran the idea past him. He pointedly told me that I was crazy for even considering it. This is rather non-trivial to handle since it means mucking around in a bunch of arch-specific code and dealing with all of the weirdo corner cases. Anyone up for working out how to handle a freeze event on a process that already has a pending signal, while it's being ptraced? It's probably best to chat with Al (cc'ed here) before you embark on this plan since he was just in that code recently. In any case, maybe there's also some code consolidation opportunity here too. I suspect at least some of this logic is in arch-specific code when it really needn't be.... -- Jeff Layton