lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 30 Aug 2016 16:13:21 +0200 From: Peter Zijlstra <peterz@...radead.org> To: Oleg Nesterov <oleg@...hat.com> Cc: Balbir Singh <bsingharora@...il.com>, LKML <linux-kernel@...r.kernel.org>, Benjamin Herrenschmidt <benh@...nel.crashing.org>, Nicholas Piggin <nicholas.piggin@...il.com> Subject: Re: [RFC][PATCH] Fix a race between rwsem and the scheduler On Tue, Aug 30, 2016 at 03:04:27PM +0200, Oleg Nesterov wrote: > On 08/30, Peter Zijlstra wrote: > > > > /* > > * Ensure we load p->on_rq _after_ p->state, otherwise it would > > * be possible to, falsely, observe p->on_rq == 0 and get stuck > > * in smp_cond_load_acquire() below. > > * > > * sched_ttwu_pending() try_to_wake_up() > > * [S] p->on_rq = 1; [L] P->state > > * UNLOCK rq->lock > > * > > * schedule() RMB > > * LOCK rq->lock > > * UNLOCK rq->lock > > * > > * [task p] > > * [S] p->state = UNINTERRUPTIBLE [L] p->on_rq > > * > > * Pairs with the UNLOCK+LOCK on rq->lock from the > > * last wakeup of our task and the schedule that got our task > > * current. > > */ > > Confused... how this connects to UNLOCK+LOCK on rq->lock? A LOAD can > leak into the critical section. How so? That LOCK+UNLOCK which is leaky, UNLOCK+LOCK is a read/write barrier (just not an MB because it lacks full transitivity). > But context switch should imply mb() we can rely on? Not sure it should, on x86 switch_mm does a CR3 write and that is serializing, but switch_to() doesn't need to do anything iirc.
Powered by blists - more mailing lists