From owner-freebsd-bugs Tue May 16 10:20: 9 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id D42BD37B9C0 for ; Tue, 16 May 2000 10:20:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id KAA20390; Tue, 16 May 2000 10:20:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Tue, 16 May 2000 10:20:01 -0700 (PDT) Message-Id: <200005161720.KAA20390@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Bosko Milekic Subject: Re: kern/18471: Checking freeing of mbufs. Reply-To: Bosko Milekic Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/18471; it has been noted by GNATS. From: Bosko Milekic To: dwmalone@maths.tcd.ie Cc: jin@george.lbl.gov, FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: kern/18471: Checking freeing of mbufs. Date: Tue, 16 May 2000 13:15:03 -0400 (EDT) Indeed, David is correct when he argues that this should be a panic, especially since it's a KASSERT(). Without even considering the other troubles the [now confused] calling code will run into, just look at what actually happens at the mcluster free routine: the "freed" cluster is attached to the mclfree list, which is essentially singly linked. When you free a cluster already in the free list, you'll basically "lose" all the clusters sitting after that one cluster on the list. This then becomes virtually a "leak" and the system is royally borked. Somebody please commit this code. --Bosko -- Bosko Milekic * pages.infinit.net/bmilekic/index.html * www.technokratis.com bmilekic@dsuper.net * bmilekic@technokratis.com * b.milekic@marianopolis.edu "Give a man a fish and he will eat for a day. Teach him how to fish, and he will sit in a boat and drink beer all day." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message