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
[EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
