Commit ff16585
committed
hal_lib: fix a race in hal_init()
This commit makes two changes in init_hal_data() (which is called by
hal_init()):
1. Take the `hal_data->mutex` using `rtapi_mutex_get()` instead of
`rtapi_mutex_try()`.
The `try` version tries to take the mutex and returns immediately,
indicating by its return value whether it actually took the mutex
or not.
Before this commit, the `init_hal_data()` function called `try` but
didn't check the return value, and just assumed that it got the mutex.
This commit switches to the `get` version, which blocks until the
mutex is available, then takes it.
Note: this relies on the promise made by rtapi_shmem_new() that a
freshly-allocated `hal_data` is initialized such that `hal_data->mutex`
is a valid, un-locked mutex.
Uspace RTAPI meets this criterion because it uses shmget(), which
initializes all shared memory to all-bytes-zero.
RTAI RTAPI also meets this criterion, though it's not mentioned in
the documentation:
https://mail.rtai.org/pipermail/rtai/2022-January/028282.html
http://cvs.savannah.nongnu.org/viewvc/rtai/magma/base/ipc/shm/shm.c?view=markup#l69
2. Take the `hal_data->mutex`, locking `hal_data`, *before* checking
whether the memory is initialized. This fixes the hal_init() race
condition.1 parent 0fe6bab commit ff16585
1 file changed
Lines changed: 15 additions & 4 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
2781 | 2781 | | |
2782 | 2782 | | |
2783 | 2783 | | |
2784 | | - | |
| 2784 | + | |
| 2785 | + | |
| 2786 | + | |
| 2787 | + | |
| 2788 | + | |
| 2789 | + | |
| 2790 | + | |
| 2791 | + | |
| 2792 | + | |
2785 | 2793 | | |
2786 | | - | |
| 2794 | + | |
2787 | 2795 | | |
| 2796 | + | |
2788 | 2797 | | |
2789 | 2798 | | |
2790 | 2799 | | |
| 2800 | + | |
2791 | 2801 | | |
2792 | 2802 | | |
2793 | 2803 | | |
2794 | | - | |
2795 | | - | |
| 2804 | + | |
| 2805 | + | |
| 2806 | + | |
2796 | 2807 | | |
2797 | 2808 | | |
2798 | 2809 | | |
| |||
0 commit comments