lwip-devel
[Top][All Lists]
Advanced

[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/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]