From owner-freebsd-current  Thu May  9 17:43:09 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id RAA17707
          for current-outgoing; Thu, 9 May 1996 17:43:09 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA17638
          Thu, 9 May 1996 17:42:55 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id KAA18101; Fri, 10 May 1996 10:40:48 +1000
Date: Fri, 10 May 1996 10:40:48 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199605100040.KAA18101@godzilla.zeta.org.au>
To: brian@mediacity.com, davidg@Root.COM
Subject: Re: Continued MBUF problem with ET V.35 card
Cc: current@FreeBSD.org, et-users@netrail.net, freebsd-isp@FreeBSD.org,
        msmith@atrad.adelaide.edu.au, randy@zyzzyva.com, stable@FreeBSD.org
Sender: owner-current@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

>   Yes, and for the record this was caused by a small change to the MGET/MFREE
>macros. We used to have a private pool of mbufs to optimize performance, but
>this was found to conflict with the allocation-type tracking in malloc() and
>lead to system instabilities. By reverting the macros back to their originals,
>the code in Dennis's driver that allocated and freed mbufs was still sticking
>them in this private pool - one the rest of the system didn't know about, and
>thus the "leak".
>   There have been no changes to the mbuf allocation code since then.

Except in -current a couple of days ago.  It no longer uses malloc() or
allocation-type tracking except for one stray allocation for `mclrefcnt'
in machdep.c.

machdep.c also refers to to the wrong entry point for the no-wait case
(kmem_alloc instead of kmem_malloc).

A comment in vm_kern.c bogusly says that "only malloc() uses this routine".
It is used by the mbuf allocation routines too.

Bruce