Memory Leaking. _talloc_zero panics

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Sun Feb 21 17:38:23 UTC 2010


On Sun, Feb 21, 2010 at 06:03:08PM +0100, Sylvain Munaut wrote:
> > I will think about how to solve this.  Either we introduce some busy-waiting
> > until more space is available, or I will try to fill existing buffers even
> > beyond the end-of-line.
> 
> I've seen the commit to fill up the msgb more. But this exposed
> another bug in msgb I think.
> The headroom allocation doesn't work AFAICT. In msgb.h there is :
> 
> static inline int msgb_tailroom(const struct msgb *msgb)
> {
>         return (msgb->data + msgb->data_len) - msgb->tail;
> }

you are right, it should be msgb->head + msgb->data_len, I've fixed
that now.

I've also changed to  busy-wait until we have msgb's available again.

dsp_dump and hello_world as well as l1test seem to work again now.

It's all still a big hack and later we need to determine if we're called
from a context that supports busy-waiting at all.

Imagine this code being executed from the FIQ context, while new memory
will always only be available from IRQ context (UART Tx FIFO interrupt):
We will deadlock.

Cheers,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)




More information about the baseband-devel mailing list