The __HAL_LOCK macro is defined as in stm32f1xx_hal_def.h
#define __HAL_LOCK(__HANDLE__) \
if((__HANDLE__)->Lock == HAL_LOCKED) \
return HAL_BUSY; \
(__HANDLE__)->Lock = HAL_LOCKED; \
So the Lock is read first and modified if needed. Would it cause race condition while the task calling __HAL_LOCK is preempted by a higher priority task which call __HAL_LOCK subsequently.
For example, task1 calls __HAL_LOCK and find the lock is open. task 1 is preempted by task2 whose priority is higher than task1 right before task1 write the Lock as HAL_LOCKED. task2 finds the lock is open and set the Lock as HAL_LOCKED. The task2 goes to block state to wait for some resource. Then task1 runs again and continue to get the lock. This will potentially corrupt the resources protect by the __HAL_LOCK for task2.
I would be happy if someone could correct me if I'm wrong since I could learn a lesson from it