From dillon@backplane.com  Fri Jun 26 17:35:51 1998
Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA09400
          for <FreeBSD-gnats-submit@freebsd.org>; Fri, 26 Jun 1998 17:35:48 -0700 (PDT)
          (envelope-from dillon@backplane.com)
Received: (dillon@localhost) by apollo.backplane.com (8.8.8/8.6.5) id RAA10806; Fri, 26 Jun 1998 17:35:15 -0700 (PDT)
Message-Id: <199806270035.RAA10806@apollo.backplane.com>
Date: Fri, 26 Jun 1998 17:35:15 -0700 (PDT)
From: Matthew Dillon <dillon@backplane.com>
Reply-To: dillon@backplane.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: Possible bug in checks for scheduler need_resched() call
X-Send-Pr-Version: 3.2

>Number:         7085
>Category:       kern
>Synopsis:       [patch] maybe_resched() priority check conditionals may be wrong.
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Jun 26 17:40:01 PDT 1998
>Closed-Date:    Wed Jul 7 03:20:35 PDT 1999
>Last-Modified:  Wed Jul  7 03:31:56 PDT 1999
>Originator:     Matthew Dillon
>Release:        FreeBSD 3.0-CURRENT i386
>Organization:
Best Internet Communications, Inc.
>Environment:

	FreeBSD-current from CVS, PPro 200

>Description:

	While searching for another bug, I found a bug in the priority
	testing code in maybe_resched().   The bug is not critical, but
	should probably be fixed.

	The problem is that maybe_resched() is not properly handling the
	case where a realtime process wakes up in the face of a normal
	process running.  It explicitly checks for the current process being
	on the idle priority queue, but that isn't good enough.  It also
	improperly calls need_resched() when one idle-queue process wakes up
	in the face of another running idle-queue process.

	Properly it should check the case where p_priority is less then
	curpriority, but ALSO check the case where the chk process's queue
	number is less (more realtime) then the current processes queue.

	Please check my work.  This bug report is not in response to an
	experienced problem, just something I saw as I was tracking down
	another problem.

>How-To-Repeat:


>Fix:
	
Index: sys/kern/kern_synch.c
===================================================================
RCS file: /src/FreeBSD-CVS/ncvs/src/sys/kern/kern_synch.c,v
retrieving revision 1.57
diff -c -r1.57 kern_synch.c
*** kern_synch.c	1998/05/28 09:30:19	1.57
--- kern_synch.c	1998/06/27 00:29:28
***************
*** 112,121 ****
  	 * the priority of the new one is higher then reschedule.
  	 */
  	if (p == 0 ||
! 	RTP_PRIO_BASE(p->p_rtprio.type) == RTP_PRIO_IDLE ||
  	(chk->p_priority < curpriority &&
! 	RTP_PRIO_BASE(p->p_rtprio.type) == RTP_PRIO_BASE(chk->p_rtprio.type)) )
  		need_resched();
  }
  
  #define ROUNDROBIN_INTERVAL (hz / quantum)
--- 112,124 ----
  	 * the priority of the new one is higher then reschedule.
  	 */
  	if (p == 0 ||
! 	/* RTP_PRIO_BASE(p->p_rtprio.type) == RTP_PRIO_IDLE || */
  	(chk->p_priority < curpriority &&
! 	RTP_PRIO_BASE(p->p_rtprio.type) == RTP_PRIO_BASE(chk->p_rtprio.type)) ||
! 	RTP_PRIO_BASE(chk->p_rtprio.type) < RTP_PRIO_BASE(p->p_rtprio.type)
! 	) {
  		need_resched();
+ 	}
  }
  
  #define ROUNDROBIN_INTERVAL (hz / quantum)
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->suspended 
State-Changed-By: phk 
State-Changed-When: Sat Jun 27 02:27:56 PDT 1998 
State-Changed-Why:  
awaiting committer 
State-Changed-From-To: suspended->closed 
State-Changed-By: bde 
State-Changed-When: Wed Jul 7 03:20:35 PDT 1999 
State-Changed-Why:  
A variant of the patch was applied by the submitter in rev.1.62.  This 
also affects RELENG_3.  RELENG_2_2 is too old for the fix to apply, but 
is only slightly less broken than -current in this area (scheduling of 
realtime processes has never really worked). 
>Unformatted:
