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

[Jilles Tjoelker]

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.

-- 
Jilles Tjoelker