From owner-freebsd-bugs Sat Jun 19 8:10: 3 1999 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 2D70F14EBD for ; Sat, 19 Jun 1999 08:10:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id IAA84582; Sat, 19 Jun 1999 08:10:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Sat, 19 Jun 1999 08:10:02 -0700 (PDT) Message-Id: <199906191510.IAA84582@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Dmitrij Tejblum Subject: Re: kern/12247: userlevel program let kernel hang Reply-To: Dmitrij Tejblum Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/12247; it has been noted by GNATS. From: Dmitrij Tejblum To: Bruce Evans Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: kern/12247: userlevel program let kernel hang Date: Sat, 19 Jun 1999 19:00:24 +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 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... Dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message