[lwip-devel] [bug #21433] Calling mem_free/pbuf_free from interrupt context isn't safe

[Jonathan Larmour]

Follow-up Comment #2, bug #21433 (project lwip):

Personally, I'm not sure I agree. This adds extra data structures, list
processing code, and does so whether the driver model requires it or not, and
I suspect many do not (mine doesn't, for example). Most importantly it does
not help raw API users with NO_SYS==1.

Otherwise if we don't care about NO_SYS==1, we can take the much simpler
approach I suggested based around tcpip_callback(), whether called directly or
indirectly through something like pbuf_free_safe.

Or perhaps, for NO_SYS==1, we just have to tell people that they have to sort
out the drivers themselves - perhaps add it to their own list which they
maintain and protect themselves. Perhaps a helper function so that drivers can
remain abstracted:

#if NO_SYS==1
#define PBUF_FREE_INT_SAFE(_p) 
    lwip_callback_pbuf_free_int_safe(_p)
#else
#define PBUF_FREE_INT_SAFE(_p) 
    tcpip_callback(pbuf_free_wrapper, (_p))
#endif

With it left to raw API users to provide a lwip_callback_pbuf_free_int_safe
function.


An alternative would be to just go ahead and add SYS_ARCH_PROTECT protection
to mem_free. Looking at the code, this doesn't seem that bad to me. There are
no non-deterministic loops, and most ISRs are likely to be longer. Or perhaps
if concerned, you could maybe release and immediately relock the protection
before the call to plug_holes(mem), then that gives any pending interrupts
time to run, thus reducing the maximum latency. But I don't think that's
needed.





    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?21433>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/