deadlocks with intr NFS mounts and ^Z (or: PCATCH and sleepable locks)

[Kostik Belousov]

On Fri, Jun 19, 2009 at 06:23:28PM +0200, Jilles Tjoelker wrote:
> I have been having trouble with deadlocks with NFS mounts for a while,
> and I have found at least one way it can deadlock. It seems an issue
> with the sleep/lock system.
> 
> NFS sleeps while holding a lockmgr lock, waiting for a reply from the
> server. When the mount is set intr, this is an interruptible sleep, so
> that interrupting signals can abort the sleep. However, this also means
> that SIGSTOP etc will suspend the thread without waking it up first, so
> it will be suspended with a lock held.
> 
> If it holds the wrong locks, it is possible that the shell will not be
> able to run, and the process cannot be continued in the normal manner.
> 
> Due to some other things I do not understand, it is then possible that
> the process cannot be continued at all (SIGCONT seems ignored), but in
> simple cases SIGCONT works, and things go back to normal.
> 
> In any case, this situation is undesirable, as even 'umount -f' doesn't
> work while the thread is suspended.
> 
> Of course, this reasoning applies to any code that goes to sleep
> interruptibly while holding a lock (sx or lockmgr). Is this supposed to
> be possible (likely useful)? If so, a third type of sleep would be
> needed that is interrupted by signals but not suspended? If not,
> something should check that it doesn't happen and NFS intr mounts may
> need to check for signals periodically or find a way to avoid sleeping
> with locks held.
> 
> The td_locks field is only accessible for the current thread, so it
> cannot be used to check if suspending is safe.
> 
> Also, making SIGSTOP and the like interrupt/restart syscalls is not
> acceptable unless you find some way to do it such that userland won't
> notice. For example, a read of 10 megabytes from a regular file with
> that much available must not return less then 10 megabytes.

See
http://lists.freebsd.org/pipermail/freebsd-smp/2009-January/001611.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090619/e6a6815e/attachment.pgp