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

[EVS Hardware Dpt]

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

I agree with Simon, the proposed patch is a good generic solution. 

Jonathan, I've looked in the stack, but when using Raw API, we don't have
such callback facilities you suggest. So the only generic way to do it so is
to check if we can free memory at a given moment, and if not, simply postpone
it when trying to allocate or to free mem.

And it does correct the problem with NO_SYS = 1 (and SYS_LIGHTWEIGHT_PROT = 1
btw), provided we have a mean to simulate Simon's function with a single
variable that is 0 or 1 to indicate the resource is locked or not. I currently
work on some simple function that could simulate that functionality.

It would be something like

typedef unsigned int lock_t;
lock_t lock_mem = 0;

#define SYS_ARCH_LOCK_RESOURCE(locked_resource)
#define SYS_ARCH_UNLOCK_RESOURCE(locked_resource)
#define SYS_ARCH_TRY_LOCKED_RESOURCE(locked_resource)

SYS_ARCH_LOCK_RESOURCE would lock a resource
SYS_ARCH_UNLOCK_RESOURCE would unlock a previously locked resource (must
verify if we must not take care of previous state for nested call support)
SYS_ARCH_TRY_LOCKED_RESOURCE would return 0 if we can access resource, or
SYS_ARCH_TIMEOUT if resource is locked.

They could be implemented as semaphore with NO_SYS = 0, and use the locked =
1/non_locked = 0 proposal.

Please tell me if it's a correct solution.

Fred.



    _______________________________________________________

Reply to this item at:

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

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