Date: Fri, 27 Sep 2002 15:06:18 -0700 From: Tom Pavel <pavel@networkphysics.com> To: freebsd-net@freebsd.org Subject: Question about mbuf allocation and VM routines Message-ID: <200209272206.g8RM6IR43626@scout.networkphysics.com>
next in thread | raw e-mail | index | archive | help
I'm working on tracking down a crash in a 4.x system that showed up as
a corruption of the kmapentzone zalloc() zone. I'm not sure what all
is unusual about my system, but I suspect one key element is that it
is using a lot more mbufs than a typical box.
Anyway, all this leads me to ask about the following code. When all
of the initial NMB_INIT mbufs are used up, the m_mballoc() routine
will add more pages to mb_map, up the limit of nmbufs. Now, all of
the MGET() and related routes set splimp, so they should serialize
access correctly between ethernet drivers and the network stack code,
for example.
int
m_mballoc(nmb, how)
register int nmb;
int how;
{
register caddr_t p;
register int i;
int nbytes;
...
nbytes = round_page(nmb * MSIZE);
p = (caddr_t)kmem_malloc(mb_map, nbytes, M_NOWAIT);
if (p == 0 && how == M_WAIT) {
mbstat.m_wait++;
p = (caddr_t)kmem_malloc(mb_map, nbytes, M_WAITOK);
}
However, as shown in this excerpt m_mballoc() calls kmem_malloc(),
which from its comments expects to be called at splhigh (or perhaps
splvm?). Ultimately, my call chain leads me to
vm_map_entry_create(mb_map), and I fear that the resulting
zalloc()/zfree() is interrupted by something else at splvm, and
thereby corrupts the kmapentzone free list. That would be consistent
with the crash I've seen.
So, my question is whether the above analysis makes sense, and whether
the kmem_malloc(M_NOWAIT) call in m_mballoc() should be wrapped in
splvm. I assume the M_WAITOK call should not be wrapped, but I
haven't thought that one through. Any other insights about this?
Many thanks,
Tom Pavel
Network Physics
pavel@networkphysics.com / pavel@alum.mit.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200209272206.g8RM6IR43626>