DragonFly bugs List (threaded) for 2010-11
Re: [issue1884] System completely freezes while listening music (devbuf: malloc limit exceeded)
:vasily postnicov <email@example.com> added the comment:
:Some code from usb_mem.c:
: * Do not free the memory unconditionally since we might be called
: * from an interrupt context and that is BAD.
: * XXX when should we really free?
: DPRINTFN(6, ("usb_block_freemem: size=%lu\n", (u_long)p->size));
: logmemory(blkfree, p, NULL, p->size, p->align);
: LIST_INSERT_HEAD(&usb_blk_freelist, p, next);
:So it, actually, does not free memory, does it?
Hmm. Well, usb_block_allocmem() will reuse it, theoretically, but
that assumes the bus_dma_tag_t is not reallocated in the mean time.
If it is then any related memory on usb_blk_freelist will just languish
there and never get reused.
:Here is some code from NetBSD I found:
:As you can see, there is some function called usb_block_real_freemem, but (as I
:understand) it is never compiled (it is between #if 0/#endif).
:What is "interrupt context" and why it is so dangerous?
The 'interrupt context' has evolved significantly over the years.
In fact on today's operating systems most interrupt contexts are
actually interrupt threads and it is in fact ok to free memory
The netbsd usb_block_real_freemem() function is enclosed in
an #if 0/#endif, so the routine is not being used.
In anycase, the usb_allocmem()/usb_freemem() code does look mighty
suspicious to me. There are two layers of caches in there (there is
also a layer in usb_allocmem() and usb_freemem()... something called
Also I don't like the way it handles dma tags in p->tag. There's this
comment in our usb_mem.c code:
/* XXX - override the tag, ok since we never free it */
p->tag = tag;