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 <FreeBSD-gnats-submit@freebsd.org>; 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 <dillon@best.net>
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 <Studded@dal.net>
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 <dillon@best.net>
To: Studded <Studded@dal.net>
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.
 		    <dillon@best.net>
     [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 <dg@root.com>
To: Matt Dillon <dillon@best.net>
Cc: Studded <Studded@dal.net>, 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 <dillon@best.net>
To: David Greenman <dg@root.com>
Cc: Studded <Studded@dal.net>, 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.
 		    <dillon@best.net>
     [always include a portion of the original email in any response!]

From: Sheldon Hearn <sheldonh@iafrica.com>
To: Matthew Dillon <dillon@apollo.backplane.com>
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 <dg@root.com>
To: Sheldon Hearn <sheldonh@iafrica.com>
Cc: Matthew Dillon <dillon@apollo.backplane.com>,
	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 <tim@localhost.nowhere>
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:
