Date: Wed, 5 Aug 1998 05:30:01 -0700 (PDT) From: Stefan Eggers <eggerss@xmailer.informatik.uni-bonn.de> To: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/7496: not so good coding in subr_rlist.c Message-ID: <199808051230.FAA15625@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/7496; it has been noted by GNATS. 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808051230.FAA15625>