From owner-freebsd-bugs Fri Jun 26 17:40:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA10134 for freebsd-bugs-outgoing; Fri, 26 Jun 1998 17:40:49 -0700 (PDT) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA10111 for ; Fri, 26 Jun 1998 17:40:32 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id RAA05541; Fri, 26 Jun 1998 17:40:01 -0700 (PDT) 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 ; 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 Reply-To: dillon@backplane.com To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: kern/7085: Possible bug in checks for scheduler need_resched() call Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 7085 >Category: kern >Synopsis: maybe_resched() priority check conditionals may be wrong. >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Jun 26 17:40:01 PDT 1998 >Last-Modified: >Originator: Matthew Dillon >Organization: Best Internet Communications, Inc. >Release: FreeBSD 3.0-CURRENT i386 >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) >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message