Tool/software: TI-RTOS
Hi Ti guys,
We have an issue in the DSPLINK dsp side.
The context:
- A pool of buffers with different buffer sizes
- The DSP is sending messages (with different buffer sizes: 128 Bytes, 256 Bytes...) to the ARM using the message queue.
- Messages "users" in DSP side don't have the same priority.
We find a bug in the following file:
dsp/src/pools/DspBios/sma_pool.c:SMAPOOL_alloc (....) or SMAPOOL_free (....)
I will only cover the ALLOC case(same as FREE case issue)
When a thread is allocating a buffer of 128 Bytes, and this thread is interrupted after "bufHandle[i].freeBuffers-- ;" (Line 273) by a thread which wants to use a buffer of 256 Bytes, this second thread will invalidate "bufHandle[i]" (Line 252) causing a memory corruption/mismatch on the 128 Bytes structure as the write back has not been done yet on it.
SMAPOOL_alloc (....)
{
.....
HAL_cacheInv ((Ptr) bufHandle, sizeof (SMAPOOL_BufObj)) ; << This line !!!
for (i = 0 ; i < smaCtrl->ctrlPtr.numBufs ; i++ ) {
if (smaCtrl->exactMatchReq == FALSE) {
/* Look for the nearest match for the requested size */
if (bufHandle[i].size >= size) {
/* Found a match for required size. */
break ;
}
}
else {
/* Look for the exact match for the requested size */
if (bufHandle[i].size == size) {
/* Found a match for required size. */
break ;
}
HAL_cacheInv ((Ptr) &bufHandle [i], sizeof (SMAPOOL_BufObj)) ; << This line !!!
}
}
We don't understand why there are invalidations here as the size is fixed during all pool life.
Could you advise ? Can we safely remove these 2 invalidations (same in SMAPOOL_free(...) ) or is there a reason to have these invalidations ?
