RTOS/CC1310: Race in kernel

Rekha R

Part Number: CC1310

Tool/software: TI-RTOS

Hi,

I am working on detecting high level races in interrupt driven programs. I selected TIRTOS for our experiments.

Our tool has detected some races in TIRTOS v2.21.01.08. For example, the accesses to swi->priority in Swi_getPri and Swi_setAttrs are in race.

(Please find the APIs below for reference.)

May I know your thoughts on this finding? Like for example, do you consider this a problem, and so on.

UInt Swi_getPri(Swi_Object *swi)
{
return (swi->priority); <<==
}

Void Swi_setAttrs(Swi_Object *swi, Swi_FuncPtr fxn, Swi_Params *params)
{
    UInt hwiKey;
    Swi_Params swiParams;

    if (params == NULL) {
        Swi_Params_init(&swiParams);
        params = &swiParams;
    }

    hwiKey = Hwi_disable();

    /* defensively remove swi from its readyQ */
    Queue_remove((Queue_Elem *)swi);

    if (fxn != NULL) {
        swi->fxn = fxn;
    }

    swi->posted = FALSE;

    swi->arg0 = params->arg0;
    swi->arg1 = params->arg1;

    if (params->priority == ~0) {
        swi->priority = Swi_numPriorities - 1;                  <<==
    }
    else {
        swi->priority = params->priority;                           <<==
    }

    Assert_isTrue((swi->priority < Swi_numPriorities),
                   Swi_A_badPriority);

    swi->mask = 1 << swi->priority;
    swi->initTrigger = swi->trigger = params->trigger;
    swi->readyQ = Queue_Object_get(Swi_module->readyQ, swi->priority);

    Hwi_restore(hwiKey);
}

Thanks

Rekha

over 6 years ago

0 ScottG over 6 years ago

TI__Mastermind 26780 points

Rekha,

Thank you for your contact about a possible race condition.

I think your concern is that the sampling of the Swi priority within Swi_getPri() is not protected by Hwi_disable()/Hwi_restore() pair, is this correct?

If yes, I agree there is a race here. But even if there were to be protection within Swi_getPri(), the instant Hwi_restore() re-enables interrupts, or even a bit later during the Swi_getPri() return sequence, the thread could be prempted and that thread could do a Swi_setAttr() - and when the original thread runs again the reported priority will also be the older priority. I think this is the general nature of APIs that sample state, if the caller is not itself protected from preemption (e.g., by its own surrounding Hwi_disable()/Hwi_restore()) then a stale state can be reported. I don't think this is a bug, but it is something that the programmer must always be thinking of in a multi-threading environment.

Was this your concern? Does this make sense?

Thanks,
Scott

0 Rekha R over 6 years ago in reply to ScottG

Intellectual 280 points

Thanks Scott for the reply.

I am not concerned much about data being stale. Like you said this is something the user must have in his mind.

I am worried about data being inconsistent like in the following situation:

The read of swi->priority in Swi_getPri() is compiled to a sequence of memory read operations.

When one half of swi->priority value is being read by thread1, it can get preempted and thread2 writes to swi->priority, atomically.

So when the control comes back to thread1 the second half is changed and thus thread1 reads an inconsistent value.

Is this situation possible?

Rekha

0 Petr Ledvina over 6 years ago in reply to Rekha R

Intellectual 480 points

From quick code search SWI priority is xdc_UInt, so compiler should emit only single instruction to read it and only 1 bus access would be performed if priority location is word aligned. Even with unaligned address and 2 bus cycles, access would be atomic on single-cpu system.

From my limited knowledge of TI-RTOS, atomic read of word from memory is assumed in the code. This detection should probably be assumed as false positive, or each detection should be checked to see if accessed variable is larger than 4bytes.

Petr

0 Rekha R over 6 years ago in reply to Petr Ledvina

Intellectual 280 points

Thanks Petr for the clarification. Based on the explanation, I agree the race detected is false positive.
I have detected some more races. Let me investigate them, based on this new info.

Hope I can get back if I still find some issue.

Thanks,
Rekha

Sub-1 GHz

Sub-1 GHz forum

RTOS/CC1310: Race in kernel