Date: Fri, 19 Jun 2009 22:46:54 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Jilles Tjoelker <jilles@stack.nl> Cc: freebsd-arch@freebsd.org Subject: Re: deadlocks with intr NFS mounts and ^Z (or: PCATCH and sleepable locks) Message-ID: <20090619194654.GC2884@deviant.kiev.zoral.com.ua> In-Reply-To: <20090619162328.GA79975@stack.nl> References: <20090619162328.GA79975@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
--TYecfFk8j8mZq+dy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > In any case, this situation is undesirable, as even 'umount -f' doesn't > work while the thread is suspended. >=20 > 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. >=20 > The td_locks field is only accessible for the current thread, so it > cannot be used to check if suspending is safe. >=20 > 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 --TYecfFk8j8mZq+dy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEQEARECAAYFAko76y0ACgkQC3+MBN1Mb4jnEQCPVJSfYUaE6l5bmEO0blk+iatx AJ9yZ4iAzLs5vCCu4Ne2vUqEMggltw== =k0BL -----END PGP SIGNATURE----- --TYecfFk8j8mZq+dy--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090619194654.GC2884>