Date: Tue, 22 Jan 2002 19:29:53 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Julian Elischer <julian@elischer.org> Cc: Alfred Perlstein <bright@mu.org>, arch@FreeBSD.ORG Subject: Re: STOP and SLEEP in the kernel Message-ID: <200201230329.g0N3Tro03179@apollo.backplane.com> References: <Pine.BSF.4.21.0201221238360.18165-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
What really freaks me out is that if t/msleep() is called with PCATCH,
it appears to process a STOP signal right then and there and actually
stop the process rather then return. t/msleep() is called all over the
place with PCATCH while holding vnode and other lockmgr locks so a ^Z
at the wrong point could deadlock the system.
"That can't be right" I said to myself and to Julian, but neither of us
can see where the code might do something else. As far as I can tell the
existing -stable and -current code *will* in fact STOP the process
while potentially holding (a vnode lock for example). There is a whole
lot of code, especially in NFS, that uses PCATCH. It can't be right.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200201230329.g0N3Tro03179>