From dillon@flea.best.net Tue Feb 3 19:54:49 1998 Received: from flea.best.net (root@flea.best.net [206.184.139.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA05886 for ; Tue, 3 Feb 1998 19:54:49 -0800 (PST) (envelope-from dillon@flea.best.net) Received: (from dillon@localhost) by flea.best.net (8.8.8/8.7.3) id TAA18111; Tue, 3 Feb 1998 19:54:18 -0800 (PST) Message-Id: <199802040354.TAA18111@flea.best.net> Date: Tue, 3 Feb 1998 19:54:18 -0800 (PST) From: Matt Dillon Reply-To: dillon@best.net To: FreeBSD-gnats-submit@freebsd.org Subject: running processes at the IDLE priority (idprio) can crash the kernel X-Send-Pr-Version: 3.2 >Number: 5641 >Category: kern >Synopsis: running processes at the IDLE priority (idprio) can crash the kernel >Confidential: no >Severity: critical >Priority: high >Responsible: jasone >State: closed >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Feb 3 20:00:01 PST 1998 >Closed-Date: Thu May 31 15:36:32 PDT 2001 >Last-Modified: Thu May 31 15:38:40 PDT 2001 >Originator: Matt Dillon >Release: FreeBSD 2.2.5-STABLE i386 >Organization: BEST Internet communications >Environment: FreeBSD 2.2.5-stable, recent CVS >Description: running processes on the IDLE queue, via idprio, can crash the kernel. >How-To-Repeat: Run a process with idprio that accesses the disk a lot. Run a cpu-bound process at normal priority Try to do other things... the kernel will crash because the process at idprio will be tsleep'ing in biowait or ufslk2 or some other critical point and create a cascade lock chain failure. >Fix: Turn the idprio off by default. Hell, get rid of it entirely, it sucks. :-) Or fix the sleep priority stuff to ensure that the process runs at a normal priority while in supervisor mode. NOTE: My previous bug reports in regards to run queue corruption are almost certainly THIS bug. The run queue is NOT corrupted. I thought it was because the process holding the base lock in the cascade failure was in a 'R'un state yet not getting any cpu. -Matt >Release-Note: >Audit-Trail: From: Studded To: freebsd-gnats-submit@freebsd.org, dillon@best.net, dg@root.com Cc: Subject: Re: kern/5641: running processes at the IDLE priority (idprio) can crash the kernel Date: Sun, 22 Mar 1998 12:42:01 -0800 Originator states that this problem is a more general form of previous problems reported (particularly 5639 where idprio is correctly identified by DG as the culprit). Consider this one a candidate for closure? Doug State-Changed-From-To: open->closed State-Changed-By: steve State-Changed-When: Sun Mar 22 13:00:47 PST 1998 State-Changed-Why: Duplicate of PR#5639 which David Grennman fixed. From: Matt Dillon To: Studded Cc: freebsd-gnats-submit@freebsd.org, dg@root.com Subject: Re: kern/5641: running processes at the IDLE priority (idprio) can crash the kernel Date: Sun, 22 Mar 1998 15:23:09 -0800 (PST) :Originator states that this problem is a more general form of previous :problems reported (particularly 5639 where idprio is correctly :identified by DG as the culprit). Consider this one a candidate for :closure? : :Doug Yes, presuming it was fixed and we aren't talking about the root-only hack (where the idprio binary was made executable only by root, or something like that). -Matt Matthew Dillon Engineering, BEST Internet Communications, Inc. [always include a portion of the original email in any response!] State-Changed-From-To: closed->open State-Changed-By: dg State-Changed-When: Sun Mar 22 20:52:59 PST 1998 State-Changed-Why: This PR needs to remain open until the problem has been properly fixed. From: David Greenman To: Matt Dillon Cc: Studded , freebsd-gnats-submit@freebsd.org Subject: Re: kern/5641: running processes at the IDLE priority (idprio) can crash the kernel Date: Sun, 22 Mar 1998 20:45:20 -0800 > Yes, presuming it was fixed and we aren't talking about the root-only > hack (where the idprio binary was made executable only by root, or > something like that). The problem has NOT been fixed. It will require scheduler changes at the very least. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From: Matt Dillon To: David Greenman Cc: Studded , freebsd-gnats-submit@freebsd.org Subject: Re: kern/5641: running processes at the IDLE priority (idprio) can crash the kernel Date: Sun, 22 Mar 1998 21:50:31 -0800 (PST) :> Yes, presuming it was fixed and we aren't talking about the root-only :> hack (where the idprio binary was made executable only by root, or :> something like that). : : The problem has NOT been fixed. It will require scheduler changes at the :very least. : :-DG : :David Greenman :Core-team/Principal Architect, The FreeBSD Project ok, got the update emails... looks all ok, you are leaving one open until the scheduler bug is fixed, great! (this was a relatively minor bug once we found it and stopped using idprio, so it isn't a big deal to us). -Matt Matthew Dillon Engineering, BEST Internet Communications, Inc. [always include a portion of the original email in any response!] From: Sheldon Hearn To: Matthew Dillon Cc: freebsd-gnats-submit@freebsd.org, dg@freebsd.org Subject: Re: kern/5641: running processes at the IDLE priority (idprio) can crash the kernel Date: Fri, 19 Mar 1999 15:52:39 +0200 Hi gents, Is the problem reported in kern/5641 something that affects 3.1-STABLE / 4.0-CURRENT? If not, does either of you have an interest in working on this in the 2.2 branch? If the answer from each of you is "no" for both of the questions above, I'll close the PR. But please do reply. :-) Thanks, Sheldon. From: David Greenman To: Sheldon Hearn Cc: Matthew Dillon , freebsd-gnats-submit@freebsd.org Subject: Re: kern/5641: running processes at the IDLE priority (idprio) can crash the kernel Date: Fri, 19 Mar 1999 07:35:05 -0800 >Is the problem reported in kern/5641 something that affects 3.1-STABLE / >4.0-CURRENT? If not, does either of you have an interest in working on >this in the 2.2 branch? Yes. >If the answer from each of you is "no" for both of the questions above, >I'll close the PR. But please do reply. :-) The problem was avoided by making idprio a superuser command. The problem is escentially a priority inversion and the solution is to elevate the priority of idprio processes to normal priority while they are executing kernel code. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project Responsible-Changed-From-To: freebsd-bugs->dg Responsible-Changed-By: unfurl Responsible-Changed-When: Thu Jul 1 18:14:20 PDT 1999 Responsible-Changed-Why: PR reassigned to last person involved in discussion. Responsible-Changed-From-To: dg->peter Responsible-Changed-By: green Responsible-Changed-When: Sat Sep 4 16:51:10 PDT 1999 Responsible-Changed-Why: Peter did the new scheduler, so it would be his area to identify whether the bug still applies and/or fix it. From: Tim Vanderhoek To: freebsd-gnats-submit@FreeBSD.org, dillon@best.net Cc: vanderh@ecf.toronto.edu Subject: Re: kern/5641: running processes at the IDLE priority Date: Sat, 20 May 2000 03:18:26 -0400 (EDT) > > Turn the idprio off by default. Hell, get rid of it entirely, it > sucks. :-) Or fix the sleep priority stuff to ensure that the > process runs at a normal priority while in supervisor mode. Add cross-reference from this PR to kern/17714, which I just closed. The kern/17714 is a lighter version of the same general priority problem. The specifics are different but the solution is the same. I'm not really sure what happened in kern/17714 but it involved two processes with different idle priorities. Perhaps this will be fixed once full-blown SMP is introduced, but either of Matt's two solutions really sound simpler... :) Responsible-Changed-From-To: peter->jasone Responsible-Changed-By: peter Responsible-Changed-When: Mon Sep 25 12:51:32 PDT 2000 Responsible-Changed-Why: Jason Evans is working on scheduling stuff. http://www.freebsd.org/cgi/query-pr.cgi?pr=5641 State-Changed-From-To: open->closed State-Changed-By: jake State-Changed-When: Thu May 31 15:36:32 PDT 2001 State-Changed-Why: This should be fixed in -current by the new new runq code and by using priority propogation mutexes for locks. http://www.FreeBSD.org/cgi/query-pr.cgi?pr=5641 >Unformatted: