forked from luck/tmp_suning_uos_patched
locking/osq_lock: Annotate a data race in osq_lock
The prev->next pointer can be accessed concurrently as noticed by KCSAN: write (marked) to 0xffff9d3370dbbe40 of 8 bytes by task 3294 on cpu 107: osq_lock+0x25f/0x350 osq_wait_next at kernel/locking/osq_lock.c:79 (inlined by) osq_lock at kernel/locking/osq_lock.c:185 rwsem_optimistic_spin <snip> read to 0xffff9d3370dbbe40 of 8 bytes by task 3398 on cpu 100: osq_lock+0x196/0x350 osq_lock at kernel/locking/osq_lock.c:157 rwsem_optimistic_spin <snip> Since the write only stores NULL to prev->next and the read tests if prev->next equals to this_cpu_ptr(&osq_node). Even if the value is shattered, the code is still working correctly. Thus, mark it as an intentional data race using the data_race() macro. Signed-off-by: Qian Cai <cai@lca.pw> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
This commit is contained in:
parent
1fe84fd4a4
commit
33190b675c
|
@ -154,7 +154,11 @@ bool osq_lock(struct optimistic_spin_queue *lock)
|
|||
*/
|
||||
|
||||
for (;;) {
|
||||
if (prev->next == node &&
|
||||
/*
|
||||
* cpu_relax() below implies a compiler barrier which would
|
||||
* prevent this comparison being optimized away.
|
||||
*/
|
||||
if (data_race(prev->next) == node &&
|
||||
cmpxchg(&prev->next, node, NULL) == node)
|
||||
break;
|
||||
|
||||
|
|
Loading…
Reference in New Issue
Block a user