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'
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.