From owner-freebsd-bugs@FreeBSD.ORG Thu Feb 2 09:40:12 2012 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABD4A1065672 for ; Thu, 2 Feb 2012 09:40:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 96E6E8FC0A for ; Thu, 2 Feb 2012 09:40:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q129eCfV012078 for ; Thu, 2 Feb 2012 09:40:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q129eCYg012077; Thu, 2 Feb 2012 09:40:12 GMT (envelope-from gnats) Date: Thu, 2 Feb 2012 09:40:12 GMT Message-Id: <201202020940.q129eCYg012077@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: kern/164705: inability to terminate process in D state X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 09:40:12 -0000 The following reply was made to PR kern/164705; it has been noted by GNATS. From: Andriy Gapon To: bug-followup@FreeBSD.org, eugene@zhegan.in Cc: Subject: Re: kern/164705: inability to terminate process in D state Date: Thu, 02 Feb 2012 11:16:56 +0200 Because you used words "completely ridiculous" in your bug report, I have to ask you what solution a genius like you can propose for a process which is stuck inside a system call (that is, in kernel). Now to techical side. FreeBSD has no problem killing processes which execute in userland. When a process is executing in kernel (in a system call), it is impossible to kill the process in a completely safe/clean fashion without affecting/corrupting internal kernel state. So bad news is that there will not be a universal kill command that can kill anything. Good news is that processes should never get stuck forever inside the kernel. Every time this happens it means that there is a (potentially new) bug in kernel, which should be properly reported and then hopefully fixed. So you will have to report concrete bugs with concrete diagnostics. See PR 164526 for a reference. P.S. In my explanation I've omitted techicalities of kill sending a signal and how the signal is delivered to its target process. -- Andriy Gapon