From seggers@semyam.dinoco.de  Tue Aug  4 23:06:14 1998
Received: from tim.xenologics.com (tim.xenologics.com [194.77.5.24])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA18767
          for <FreeBSD-gnats-submit@freebsd.org>; Tue, 4 Aug 1998 23:06:07 -0700 (PDT)
          (envelope-from seggers@semyam.dinoco.de)
Received: (from uucp@localhost)
	by tim.xenologics.com (8.8.5/8.8.8) with UUCP id IAA10003
	for FreeBSD-gnats-submit@freebsd.org; Wed, 5 Aug 1998 08:02:45 +0200 (MET DST)
Received: (from seggers@localhost)
	by semyam.dinoco.de (8.8.8/8.8.8) id IAA01780;
	Wed, 5 Aug 1998 08:01:39 +0200 (CEST)
	(envelope-from seggers)
Message-Id: <199808050601.IAA01780@semyam.dinoco.de>
Date: Wed, 5 Aug 1998 08:01:39 +0200 (CEST)
From: Stefan Eggers <seggers@semyam.dinoco.de>
Reply-To: seggers@semyam.dinoco.de
To: FreeBSD-gnats-submit@freebsd.org
Cc: seggers@semyam.dinoco.de
Subject: not so good coding in subr_rlist.c
X-Send-Pr-Version: 3.2

>Number:         7496
>Category:       kern
>Synopsis:       not so good coding in subr_rlist.c
>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:   Tue Aug  4 23:10:01 PDT 1998
>Closed-Date:    Wed Aug 5 07:06:56 PDT 1998
>Last-Modified:  Wed Aug  5 07:07:23 PDT 1998
>Originator:     Stefan Eggers
>Release:        FreeBSD 3.0-CURRENT i386
>Organization:
none
>Environment:

	N/A

>Description:

	While reading the source I noticed that in rlist_free in the
file kern/subr_rlist.c a pointer gets intialized before the list the
pointed to node is on was locked.

	This would lead to serious trouble if rlist_free could sleep
or if some other functions get added which manipulate the list.  This
fortunately seems not to happen, yet but is a potential source of
problems I think.  Even if not one can argue that someone trying to
learn from this source should get a cleaner version.

>How-To-Repeat:

	N/A

>Fix:
	
--- subr_rlist.c.ORIG	Tue Jul 14 12:47:28 1998
+++ subr_rlist.c	Wed Aug  5 07:47:30 1998
@@ -118,7 +118,7 @@
 	u_int start, end;
 {
 	struct rlist **rlp = &rlh->rlh_list;
-	struct rlist *prev_rlp = NULL, *cur_rlp = *rlp, *next_rlp = NULL;
+	struct rlist *prev_rlp = NULL, *cur_rlp, *next_rlp = NULL;
 	int s;
 
 	s = splhigh();
@@ -133,6 +133,7 @@
 	 * Traverse the list looking for an entry after the one we want
 	 * to insert.
 	 */
+	cur_rlp = *rlp;
 	while (cur_rlp != NULL) {
 		if (start < cur_rlp->rl_start)
 			break;
>Release-Note:
>Audit-Trail:

From: Stefan Eggers <eggerss@xmailer.informatik.uni-bonn.de>
To: freebsd-gnats-submit@freebsd.org, seggers@semyam.dinoco.de
Cc:  Subject: Re: kern/7496: not so good coding in subr_rlist.c
Date: Wed, 05 Aug 1998 14:23:32 +0200

 Thinking more about the possible implications I came to
 conclude this can cause loss of memory and swap space in
 certain cases.  Maybe I'm wrong but if not it's a nasty
 bug.  :-(
 
 Let's suppose a process X has the lock at present and two
 other processes named A and B want to free a range but
 have to wait till the resource list is unlocked.
 
 The process A wants to free 1-2, process B frees 3-4 and
 the resource lists contains 7-9, 22-55, ... after process
 X is finished with it.
 
 At some point in time hopefully process X will release the
 lock and wake up the other processes waiting for it.  One
 of the processes (lets choose A for now) is the lucky one
 and can complete its operation.  The resource list after-
 ward is 1-2, 7-9, 22-55, ...  So far, so good.
 
 Now process B gets its turn and sees 7-9 as first entry to
 the list and due to the pointer to the previous node being
 NULL concludes wrongly that this the first enty and adds its
 new node in a way that looses the reference to the entry for
 1-2 which process A entered a little bit ago.  We lost track
 of memory and part of the managed resource.
 
 Stefan.
State-Changed-From-To: open->closed 
State-Changed-By: dg 
State-Changed-When: Wed Aug 5 07:06:56 PDT 1998 
State-Changed-Why:  
I agree that there appears to be a real bug there. I've committed your fix. 
Thanks for the bug report! 
>Unformatted:
