3038
|
|
|
Kienan Stewart |
11 months ago
|
|
|
3037
|
|
|
Kienan Stewart |
11 months ago
|
|
|
3036
|
|
|
Michael Jeanson |
11 months ago
|
|
|
3035
|
|
|
Michael Jeanson |
11 months ago
|
|
|
3034
|
|
|
Michael Jeanson |
1 year ago
|
|
|
3033
|
|
|
Mathieu Desnoyers |
1 year ago
|
|
|
3032
|
|
|
Mathieu Desnoyers |
1 year ago
|
|
|
3031
|
|
|
Mathieu Desnoyers |
1 year ago
|
|
|
3030
|
|
|
Michael Jeanson |
1 year ago
|
|
|
3029
|
|
|
Mathieu Desnoyers |
1 year ago
|
|
|
3028
|
|
|
Jonathan Rajotte |
1 year ago
|
|
|
3027
|
|
|
Kienan Stewart |
1 year ago
|
|
|
3026
|
|
|
Mathieu Desnoyers |
1 year ago
|
|
|
3025
|
|
|
Jérémie Galarneau |
1 year ago
|
|
|
3024
|
|
|
Olivier Dion |
1 year ago
|
|
|
3023
|
|
|
Olivier Dion |
1 year ago
|
|
|
3022
|
|
ustfork: Fix possible race conditions
Assuming that `dlsym(RTLD_NEXT, "symbol")' is invariant for "symbol", then we could think that memory operations on the `plibc_func' pointers can be safely done without atomics.
However, consider what would happen if a load to a`plibc_func' pointer is torn apart by the compiler. Then a thread could see:
1) NULL
2) The stored value as returned by a dlsym() call
3) A mix of 1) and 2)
The same goes for other optimizations that a compiler is authorized to do (e.g. store tearing, load fusing).
One could question whether such race condition is even possible for the clone(2) wrapper. Indeed, a thread must be cloned to get into existence. Therefore, the main thread would always store the value of `plibc_func' at least once before creating the first sibling thread, preventing any possible race condition for this wrapper. However, this assume that the main thread will not call the clone system call directly before calling the libc wrapper! Thus, to be on the safe side, we do the same for the clone wrapper.
Fix the race conditions by using the uatomic_read/uatomic_set functions, on access to `plibc_func' pointers.
Change-Id: Ic4be25983b8836d2b333f367af9c18d2f6b75879 Signed-off-by: Olivier Dion <odion@efficios.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
|
Olivier Dion |
1 year ago
|
|
|
3021
|
|
|
Mathieu Desnoyers |
1 year ago
|
|
|
3020
|
|
|
Michael Jeanson |
1 year ago
|
|
|
3019
|
|
|
Michael Jeanson |
1 year ago
|
|
|