[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-devel] [bug #21433] Calling mem_free/pbuf_free from interrupt cont
From: |
Jonathan Larmour |
Subject: |
[lwip-devel] [bug #21433] Calling mem_free/pbuf_free from interrupt context isn't safe |
Date: |
Tue, 30 Oct 2007 16:49:48 +0000 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.12) Gecko/20070530 Fedora/1.5.0.12-1.fc5 Firefox/1.5.0.12 |
Follow-up Comment #10, bug #21433 (project lwip):
plug_holes isn't a problem - for sure it would not be the largest part in a
system that is run with interrupts off (certainly not if you have ISRs is
doing things like pbuf_free!).
For the connection with heap size, I think I see what you're getting at -
some interrupt-driven drivers want to call mem_free, not mem_alloc; but
mem_free/mem_alloc need mutual exclusion from each other.
That's a slightly different problem with less intrusive possible solutions.
For example, we can assume the chances of a driver mem_free() occuring in the
middle of a mem_alloc() are very small. Small enough we can do something
relatively inefficient in the unlikely case it occurs, such as changing
mem_free to something like:
static volatile u8_t mem_free_count;
SYS_ARCH_PROTECT(level);
ptr = (u8_t *)lfree - ram;
do {
mem = (struct mem *)&ram[ptr];
mem_free_count=0;
SYS_ARCH_UNPROTECT(level);
/* Blip interrupt-protection to avoid high
* interrupt latency
*/
SYS_ARCH_PROTECT(level);
if ( mem_free_count != 0 ) {
/* An interrupt did a free. Restart search. */
ptr = (u8_t *)lfree - ram;
continue;
}
if ((!mem->used) &&
(mem->next - (ptr + SIZEOF_STRUCT_MEM)) >= size) {
[etc. as before]
}
ptr = ((struct mem *)&ram[ptr])->next) {
while ( ptr < MEM_SIZE_ALIGNED - size );
and having mem_free() set mem_free_count;
But whatever the solution, personally I think that this is going to affect
few drivers. I would have guessed (possibly wrongly) that most ethernet driver
systems do operate at thread level because the amount of processing,
especially copying, that would otherwise happen at interrupt level would make
interrupt latency dreadful. At best it should be an option. Just my opinion
though.
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/bugs/?21433>
_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/
- [lwip-devel] [bug #21433] Calling mem_free/pbuf_free from interrupt context isn't safe, (continued)
- [lwip-devel] [bug #21433] Calling mem_free/pbuf_free from interrupt context isn't safe, Simon Goldschmidt, 2007/10/25
- [lwip-devel] [bug #21433] Calling mem_free/pbuf_free from interrupt context isn't safe, Jonathan Larmour, 2007/10/25
- [lwip-devel] [bug #21433] Calling mem_free/pbuf_free from interrupt context isn't safe, EVS Hardware Dpt, 2007/10/26
- [lwip-devel] [bug #21433] Calling mem_free/pbuf_free from interrupt context isn't safe, EVS Hardware Dpt, 2007/10/26
- [lwip-devel] [bug #21433] Calling mem_free/pbuf_free from interrupt context isn't safe, Simon Goldschmidt, 2007/10/26
- [lwip-devel] [bug #21433] Calling mem_free/pbuf_free from interrupt context isn't safe, Frédéric Bernon, 2007/10/28
- [lwip-devel] [bug #21433] Calling mem_free/pbuf_free from interrupt context isn't safe, EVS Hardware Dpt, 2007/10/29
- [lwip-devel] [bug #21433] Calling mem_free/pbuf_free from interrupt context isn't safe, EVS Hardware Dpt, 2007/10/30
- [lwip-devel] [bug #21433] Calling mem_free/pbuf_free from interrupt context isn't safe, Jonathan Larmour, 2007/10/30
- [lwip-devel] [bug #21433] Calling mem_free/pbuf_free from interrupt context isn't safe, EVS Hardware Dpt, 2007/10/30
- [lwip-devel] [bug #21433] Calling mem_free/pbuf_free from interrupt context isn't safe,
Jonathan Larmour <=