From trost@cloud.rain.com  Fri Mar 31 12:13:10 2000
Return-Path: <trost@cloud.rain.com>
Received: from grey.cloud.rain.com (c1029014-a.bvrtn1.or.home.com [24.12.160.67])
	by hub.freebsd.org (Postfix) with ESMTP id EAD7837BE71
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 31 Mar 2000 12:13:09 -0800 (PST)
	(envelope-from trost@cloud.rain.com)
Received: (qmail 82280 invoked by uid 236); 31 Mar 2000 20:13:07 -0000
Message-Id: <20000331201307.82279.qmail@grey.cloud.rain.com>
Date: 31 Mar 2000 20:13:07 -0000
From: trost@cloud.rain.com
Reply-To: trost@cloud.rain.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: possible priority inversion with use of idprio
X-Send-Pr-Version: 3.2

>Number:         17714
>Category:       kern
>Synopsis:       possible priority inversion with use of idprio
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Mar 31 12:20:01 PST 2000
>Closed-Date:    Sat May 20 00:24:06 PDT 2000
>Last-Modified:  Sat May 20 00:27:04 PDT 2000
>Originator:     Bill Trost
>Release:        FreeBSD 4.0-20000208-CURRENT i386
>Organization:
Trost Computing
>Environment:

	Uhh...single 400 MHz Pentium, single IDE drive...not sure what else
	would matter.

>Description:

	I have a startup script that starts setiathome at an idprio of
	31 and then starts up gf_client (a distributed gamma ray flux
	project) at an idprio of 30.  After startup, I noticed that "ps"
	had an "L" flag in the "STAT" column for setiathome (the lowest
	priority process).  The next command, "man ps", hung; then,
	"date" (or, more likely, the shell) hung in another window. At
	this point, I interrupted gf_client, and everything started
	working again.

	I presume that the problem was cause by a priority inversion
	where the setiathome client had somehow locked a page, but
	could not do whatever needed to be done with the page because
	gf_client was taking all available CPU cycles.

>How-To-Repeat:

	Hah!  Good luck!  I have no idea how to make a process keep
	pages locked in core long enough to cause the problem.

>Fix:

	I would guess that locking a page in core should cause an
	increase in the process's priority, but I know nothing of the
	details.


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: hoek 
State-Changed-When: Sat May 20 00:24:06 PDT 2000 
State-Changed-Why:  
You are correct that idprio has a priority inversion problem.  I 
am not sure about your hypothesized explanation, but the general 
problem is known and there is an earlier open PR describing the 
problem. 

Thanks. 

References: sys/kern/kern_synch.c and kern/5641 

The problem is not expected to be solved in the short term.  Hehe. 
Fixing it is a low-priority task for us.  :) 
>Unformatted:
