xtimer: check in xtimer_mutex_lock_timeout timeout callback if a thread blocked on mutex

[pwillem]

Contribution description

Prevent a possible race condition for xtimer_mutex_lock_timeout when _mutex_timeout fires just after the mutex was locked but before the xtimer was removed

The flow

int xtimer_mutex_lock_timeout(mutex_t *mutex, uint64_t timeout) {
   ...
    mutex_lock(mutex);
    <- mutex locked ->
    <- _mutex_timeout fires and tries to remove thread from mutex queue ->
    xtimer_remove(&t);
    ...
}

Testing procedure

I didn't try to reproduce the bug because a backtrace was provided

gdb) bt#0  0x080558e2 in list_remove (list=0xffffffff, node=0x20008094 <_stack+1912>) at /RIOT/core/include/list.h:88
#1  0x08055a7a in _mutex_timeout (arg=0x20007f68 <_stack+1612>) at /RIOT/sys/xtimer/xtimer.c:241
#2  0x0800375c in _shoot (timer=0x20007f74 <_stack+1624>) at /RIOT/sys/xtimer/xtimer_core.c:166
#3  0x08003c36 in _timer_callback () at /RIOT/sys/xtimer/xtimer_core.c:517
#4  0x08003740 in _periph_timer_callback (arg=0x0, chan=0) at /RIOT/sys/xtimer/xtimer_core.c:161
#5  0x08004a74 in irq_handler (tim=0) at /RIOT/cpu/stm32_common/periph/timer.c:116
#6  0x08004a9a in isr_tim5 () at /RIOT/cpu/stm32_common/periph/timer.c:125
#7  <signal handler called>
#8  0x080010de in cpu_switch_context_exit () at /RIOT/cpu/cortexm_common/thread_arch.c:266
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

gdb) bt#0  0x080010f8 in thread_yield_higher () at /RIOT/cpu/cortexm_common/thread_arch.c:280
#1  0x08000afc in _mutex_lock (mutex=0x2000a1f0 <_rsp_available>, blocking=1) at /RIOT/core/mutex.c:62
#2  0x08055908 in mutex_lock (mutex=0x2000a1f0 <_rsp_available>) at /RIOT/core/include/mutex.h:113
#3  0x08055b02 in xtimer_mutex_lock_timeout (mutex=0x2000a1f0 <_rsp_available>, timeout=500000) at /RIOT/sys/xtimer/xtimer.c:261

Issues/PRs references

Didn't create an issues

[vincent-d]

I just remembered that there was another PR which has been opened for quite some time now which may be better than this one because it covers more corner cases: #6441.

Maybe we should try to have it in instead of this one.

[MichelRottleuthner]

Closing in favor of #11992 (which also contains the changes from this PR)