lkml.org 
[lkml]   [2018]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 2/3] locking: Clarify requirements for smp_mb__after_spinlock()
On Mon, Jul 02, 2018 at 05:11:55PM +0200, Andrea Parri wrote:
> /*
> + * smp_mb__after_spinlock() provides the equivalent of a full memory barrier
> + * between program-order earlier lock acquisitions and program-order later
> + * memory accesses.
> *
> + * This guarantees that the following two properties hold:
> *
> + * 1) Given the snippet:
> *
> + * { X = 0; Y = 0; }
> *
> + * CPU0 CPU1
> *
> + * WRITE_ONCE(X, 1); WRITE_ONCE(Y, 1);
> + * spin_lock(S); smp_mb();
> + * smp_mb__after_spinlock(); r1 = READ_ONCE(X);
> + * r0 = READ_ONCE(Y);
> + * spin_unlock(S);
> *
> + * it is forbidden that CPU0 does not observe CPU1's store to Y (r0 = 0)
> + * and CPU1 does not observe CPU0's store to X (r1 = 0); see the comments
> + * preceding the call to smp_mb__after_spinlock() in __schedule() and in
> + * try_to_wake_up().
> + *
> + * 2) Given the snippet:
> + *
> + * { X = 0; Y = 0; }
> + *
> + * CPU0 CPU1 CPU2
> + *
> + * spin_lock(S); spin_lock(S); r1 = READ_ONCE(Y);
> + * WRITE_ONCE(X, 1); smp_mb__after_spinlock(); smp_rmb();
> + * spin_unlock(S); r0 = READ_ONCE(X); r2 = READ_ONCE(X);
> + * WRITE_ONCE(Y, 1);
> + * spin_unlock(S);
> + *
> + * it is forbidden that CPU0's critical section executes before CPU1's
> + * critical section (r0 = 1), CPU2 observes CPU1's store to Y (r1 = 1)
> + * and CPU2 does not observe CPU0's store to X (r2 = 0); see the comments
> + * preceding the calls to smp_rmb() in try_to_wake_up() for similar
> + * snippets but "projected" onto two CPUs.

Maybe explicitly note that 2) is the RCsc lock upgrade.


> * Since most load-store architectures implement ACQUIRE with an smp_mb() after
> * the LL/SC loop, they need no further barriers. Similarly all our TSO
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index da8f12119a127..ec9ef0aec71ac 100644
> +++ b/kernel/sched/core.c
> @@ -1999,21 +1999,20 @@ try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags)
> * 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()
> + * STORE p->on_rq = 1 LOAD p->state
> + * UNLOCK rq->lock
> + *
> + * __schedule() (switch to task 'p')
> + * LOCK rq->lock smp_rmb();
> + * smp_mb__after_spinlock();
> + * UNLOCK rq->lock
> *
> * [task p]
> + * STORE p->state = UNINTERRUPTIBLE LOAD p->on_rq
> *
> + * Pairs with the LOCK+smp_mb__after_spinlock() on rq->lock in
> + * __schedule(). See the comment for smp_mb__after_spinlock().
> */
> smp_rmb();
> if (p->on_rq && ttwu_remote(p, wake_flags))
> @@ -2027,15 +2026,17 @@ try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags)
> * One must be running (->on_cpu == 1) in order to remove oneself
> * from the runqueue.
> *
> + * __schedule() (switch to task 'p') try_to_wake_up()
> + * STORE p->on_cpu = 1 LOAD p->on_rq
> + * UNLOCK rq->lock
> + *
> + * __schedule() (put 'p' to sleep)
> + * LOCK rq->lock smp_rmb();
> + * smp_mb__after_spinlock();
> + * STORE p->on_rq = 0 LOAD p->on_cpu
> *
> + * Pairs with the LOCK+smp_mb__after_spinlock() on rq->lock in
> + * __schedule(). See the comment for smp_mb__after_spinlock().
> */
> smp_rmb();

Ah yes, good.

Ack!

\
 
 \ /
  Last update: 2018-07-02 17:38    [W:0.597 / U:1.648 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site