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

[Tejun Heo]

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.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/