Date: Sun, 20 Jun 1999 12:40:02 -0700 (PDT) From: Dmitrij Tejblum <tejblum@arc.hq.cti.ru> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/12247: userlevel program let kernel hang Message-ID: <199906201940.MAA88933@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/12247; it has been noted by GNATS. From: Dmitrij Tejblum <tejblum@arc.hq.cti.ru> To: Bruce Evans <bde@zeta.org.au> Cc: tejblum@arc.hq.cti.ru, freebsd-gnats-submit@FreeBSD.ORG Subject: Re: kern/12247: userlevel program let kernel hang Date: Sun, 20 Jun 1999 23:37:44 +0400 Bruce Evans wrote: > >> tsleep()'s return codes are poorly documented and were > >> misinterpreted in lf_setlock(). tsleep() can return 0 if the process > >> was restarted by a debugger, > > > >I didn't realise that a process sleeping interruptible can be stopped > >inside the tsleep call (is that true?). It looks dangerous to me. For > > I think it isn't true. No I've verified that both kill -STOP and gdb attach move process to the stopped state without wakeing it up. > > >example, interruptible nfs may sleep interuuptible, in particular in > >the vfs_bio code, with vnode locks held, etc. Stopping at such point > >looks like a good opportunity to hang the machine... > > PT_ATTACH is implemented using SIGSTOP, but the consequences shouldn't > be any worse than for a manual kill -STOP. I think SIGSTOP of a stopped > process is normally optimised away (so tsleep() doesn't return), but for > ptrace() it is explicitly pessimised (so tsleep() returns 0). I think, while psignal() make process runnable in most cases, the process then stuck in issignal() if stopped. I'm not saying that kill -STOP is less dangerous than ptrace(). Dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906201940.MAA88933>