Date: Fri, 19 Jun 2009 18:23:28 +0200 From: Jilles Tjoelker <jilles@stack.nl> To: freebsd-arch@freebsd.org Subject: deadlocks with intr NFS mounts and ^Z (or: PCATCH and sleepable locks) Message-ID: <20090619162328.GA79975@stack.nl>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090619162328.GA79975>