Messages in this thread | | | Date | Wed, 22 Jan 2020 18:09:44 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH] locking/osq_lock: fix a data race in osq_wait_next |
| |
On Wed, Jan 22, 2020 at 11:38:57AM -0500, Qian Cai wrote: > KCSAN complains, > > write (marked) to 0xffff941ca3b3be00 of 8 bytes by task 670 on cpu 6: > osq_lock+0x24c/0x340 > __mutex_lock+0x277/0xd20 > mutex_lock_nested+0x31/0x40 > memcg_create_kmem_cache+0x2e/0x190 > memcg_kmem_cache_create_func+0x40/0x80 > process_one_work+0x54c/0xbe0 > worker_thread+0x80/0x650 > kthread+0x1e0/0x200 > ret_from_fork+0x27/0x50 > > read to 0xffff941ca3b3be00 of 8 bytes by task 703 on cpu 44: > osq_lock+0x18e/0x340 > __mutex_lock+0x277/0xd20 > mutex_lock_nested+0x31/0x40 > memcg_create_kmem_cache+0x2e/0x190 > memcg_kmem_cache_create_func+0x40/0x80 > process_one_work+0x54c/0xbe0 > worker_thread+0x80/0x650 > kthread+0x1e0/0x200 > ret_from_fork+0x27/0x50
That's useless gibberish, at the very least run it through some decode so we get line numbers.
> which points to those lines in osq_wait_next(), > > next = xchg(&node->next, NULL); > if (next) > break; > > Since only the read is outside of critical sections, fixed it by adding > a READ_ONCE().
What?!?! Did you actually read what you wrote?
Also, you have to stop calling things fixes unless you can prove (and explain) there is an actual problem.
> Signed-off-by: Qian Cai <cai@lca.pw> > --- > kernel/locking/osq_lock.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/locking/osq_lock.c b/kernel/locking/osq_lock.c > index 6ef600aa0f47..8f565165019a 100644 > --- a/kernel/locking/osq_lock.c > +++ b/kernel/locking/osq_lock.c > @@ -77,7 +77,7 @@ osq_wait_next(struct optimistic_spin_queue *lock, > */ > if (node->next) { > next = xchg(&node->next, NULL); > - if (next) > + if (READ_ONCE(next)) > break; > } >
This seems to suggest you ought to maybe brush up on your C skills.
| |