Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Jan 2001 11:06:42 -0600
From:      Robert Lipe <robertlipe@usa.net>
To:        freebsd-hackers@FreeBSD.ORG
Subject:   contigmalloc, M_WAITOK, & leaks.
Message-ID:  <20010122110642.B10504@rjlhome.sco.com>

next in thread | raw e-mail | index | archive | help
Hi, Gang.

I know that anytime a message starts with a subject like this, the
first reaction is to think that I've hosed the heap or am not freeing
something.  While it's possible, I really don't think I have.  (I also
know that everyone thinks that. :-)

I'm on FreeBSD 4.1.1.  I've not seen any flagrantly smoking guns since
then in vm_page.c, although version 1.154 might be...

I'm calling contigmalloc() with M_WAITOK.  For every contigmalloc, I
have a corresponding contigfree().  But after a few thousand cycles,
contigmalloc() starts returning NULL.  It self-destructs in about 3
minutes.  I see the same behaviour with M_NOWAIT.  As an aside, WAITOK's
should never return NULL, right?  They should be put to sleep and
awakened when the resource is available.

So I'm suspecting there are two problems (they may be problems in my
understanding and not the code): One is that we leak something that
makes it fail.  The other is that M_WAITOK isn't honoured when it does
fail.

Fortunately, the allocations in question for my test have really simple
constraints.  I know that it's *really* calling contigmalloc with single
byte alignment that can be located anywhere in 32-bit address space
and I'm on a 32-bit host.  If I replace contigmalloc/contigfree with
malloc/free it runs fine for hours.  Since all I did was replace the
single call site of each, I really don't think I'm leaking it.  While
this is a cute special case (and presumably a potential optimization),
it's also not typical of real hardware in real systems that have to have
real constraints passed to contigmalloc.

Looking at the callers of contigmalloc/contigfree in the tree, I don't
see a lot of highly dynamic uses of them.  For the most part, drivers
are making a low number of calls at attachment time and a low number of
releases at detachment time.   Thus, it's possible that a problem here
could have gone unnoticed.

Any ideas?  Is there something magic to contig management?  Do I have to
hold an elevated PL during calls to these to prevent corruption?

Thanx,
RJL


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010122110642.B10504>