RTOS/LINUXSDK-OMAPL138: DSPLINK 1_65_01_06 cache/memory corruption issue in sma pool handle structure

Part Number:LINUXSDK-OMAPL138

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 ?