Date: Thu, 28 May 2015 15:10:31 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 200493] Killing pid 11 (idle) wedges the disk IO Message-ID: <bug-200493-8-f6jG2tW6Wx@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-200493-8@https.bugs.freebsd.org/bugzilla/> References: <bug-200493-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200493 Konstantin Belousov <kib@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kib@FreeBSD.org --- Comment #1 from Konstantin Belousov <kib@FreeBSD.org> --- (In reply to Edward Tomasz Napierala from comment #0) It is very _weird_ bug report from developer. You did not invesigated what is the state of the idle (?) process after the kill, obviously pid value does not matter since kernel starts variable number of the kprocs during the boot (on my kernel idle has pid 10). And last and most important, kernel processes do not process signals: there is no place where cursig()/postsig() pair is called, since there is no return from kernel to user mode, and no ast handler called. E.g. after I do kill -9 10 (pid 10 is my idle process), I see sandy% sudo procstat -i 10 PID COMM SIG FLAGS 10 idle KILL P-- I.e. SIGKILL was put into the queue, but nothing processed it. And I do not observe any weirdness in the system behaviour afterward. If your system consumed the SIGKILL, there should be some code which called postsig() in the context of the idle threads. FYI, the idle loop is sched_idletd(), private for the given scheduler implementation. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-200493-8-f6jG2tW6Wx>