Date: Tue, 22 Jan 2002 20:42:12 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Alfred Perlstein <bright@mu.org>, Julian Elischer <julian@elischer.org> Cc: arch@freebsd.org, Bruce Evans <bde@zeta.org.au>, David Greenman <dg@root.com> Subject: PCATCH vs signal(SIGSTOP) (was Re: STOP and SLEEP in the kernel) Message-ID: <200201230442.g0N4gCh03552@apollo.backplane.com> References: <Pine.BSF.4.21.0201221238360.18165-100000@InterJet.elischer.org> <200201230329.g0N3Tro03179@apollo.backplane.com> <20020122203517.I13686@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:* Matthew Dillon <dillon@apollo.backplane.com> [020122 19:30] wrote:
:> 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.
:
:*ARRRRRRGH*
:
:Obviously STOP signals should only be honoured in userret and signal
:entry points. Any chance for a fix?
:
:--
:-Alfred Perlstein [alfred@freebsd.org]
I'm still not sure it even happens, but I can't find any code to
prevent it.
I would like somebody whos played with the signal code before, like
BDE or DG, to take a look at the STOP/PCATCH handling.
For those I've just added to the CC: Julian and I were looking at
the STOP signal handling code and it appears that a tsleep()/msleep()
called with PCATCH can cause the process to go into a STOPped state if
it is signaled at just that moment, leaving held locks in place and
potentially deadlocking the system. There is a whole lot of code in
the kernel that uses PCATCH and assumes that tsleep()/msleep() will
return when a signal occurs rather then the process being stopped.
If it is indeed hapenning the way I fear, the fix should be easy. The
question is... is it hapenning the way I fear?
-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?200201230442.g0N4gCh03552>