Re: LOCKDEP: 3.9-rc1: mount.nfs/4272 still has locks held!

[Jeff Layton <jlayton@redhat.com>]

On Tue, 5 Mar 2013 09:49:54 -0800
Tejun Heo <tj@kernel.org> wrote:

> On Tue, Mar 05, 2013 at 09:46:48AM -0800, Tejun Heo wrote:
> > So, I think this is why implementing freezer as a separate blocking
> > mechanism isn't such a good idea.  We're effectively introducing a
> > completely new waiting state to a lot of unsuspecting paths which
> > generates a lot of risks and eventually extra complexity to work
> > around those.  I think we really should update freezer to re-use the
> > blocking points we already have - the ones used for signal delivery
> > and ptracing.  That way, other code paths don't have to worry about an
> > extra stop state and we can confine most complexities to freezer
> > proper.
> 
> Also, consolidating those wait states means that we can solve the
> event-to-response latency problem for all three cases - signal, ptrace
> and freezer, rather than adding separate backing-out strategy for
> freezer.
> 

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?

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.

Sounds horrific to code up though... :)

-- 
Jeff Layton <jlayton@redhat.com>