From owner-freebsd-bugs Wed Aug 5 05:30:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA06380 for freebsd-bugs-outgoing; Wed, 5 Aug 1998 05:30:04 -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 FAA06375 for ; Wed, 5 Aug 1998 05:30:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id FAA15625; Wed, 5 Aug 1998 05:30:01 -0700 (PDT) Date: Wed, 5 Aug 1998 05:30:01 -0700 (PDT) Message-Id: <199808051230.FAA15625@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: Stefan Eggers Subject: Re: kern/7496: not so good coding in subr_rlist.c Reply-To: Stefan Eggers Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/7496; it has been noted by GNATS. From: Stefan Eggers 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message