All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Andrea Parri <parri.andrea@gmail.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Boqun Feng <boqun.feng@gmail.com>, Andrew Hunter <ahh@google.com>,
	maged michael <maged.michael@gmail.com>,
	gromer <gromer@google.com>, Avi Kivity <avi@scylladb.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Dave Watson <davejwatson@fb.com>
Subject: Re: [PATCH] membarrier: Document scheduler barrier requirements
Date: Tue, 19 Sep 2017 19:56:55 +0000 (UTC)	[thread overview]
Message-ID: <1663138547.13906.1505851015752.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <20170919002642.GA3653@andrea>

----- On Sep 18, 2017, at 8:26 PM, Andrea Parri parri.andrea@gmail.com wrote:

> On Mon, Sep 18, 2017 at 02:01:22PM -0400, Mathieu Desnoyers wrote:
>> Document the membarrier requirement on having a full memory barrier in
>> __schedule() after coming from user-space, before storing to rq->curr.
>> It is provided by smp_mb__before_spinlock() in __schedule().
>> 
>> Document that membarrier requires a full barrier on transition from
>> kernel thread to userspace thread. We currently have an implicit barrier
>> from atomic_dec_and_test() in mmdrop() that ensures this.
>> 
>> The x86 switch_mm_irqs_off() full barrier is currently provided by many
>> cpumask update operations as well as write_cr3(). Document that
>> write_cr3() provides this barrier.
>> 
>> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
>> CC: Peter Zijlstra <peterz@infradead.org>
>> CC: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>> CC: Boqun Feng <boqun.feng@gmail.com>
>> CC: Andrew Hunter <ahh@google.com>
>> CC: Maged Michael <maged.michael@gmail.com>
>> CC: gromer@google.com
>> CC: Avi Kivity <avi@scylladb.com>
>> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> CC: Paul Mackerras <paulus@samba.org>
>> CC: Michael Ellerman <mpe@ellerman.id.au>
>> CC: Dave Watson <davejwatson@fb.com>
>> ---
>>  arch/x86/mm/tlb.c        | 5 +++++
>>  include/linux/sched/mm.h | 4 ++++
>>  kernel/sched/core.c      | 9 +++++++++
>>  3 files changed, 18 insertions(+)
>> 
>> diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
>> index 1ab3821f9e26..fa3bbe048af0 100644
>> --- a/arch/x86/mm/tlb.c
>> +++ b/arch/x86/mm/tlb.c
>> @@ -144,6 +144,11 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct
>> mm_struct *next,
>>  	}
>>  #endif
>>  
>> +	/*
>> +	 * The membarrier system call requires a full memory barrier
>> +	 * after coming from user-space, before storing to rq->curr.
> 
> I'm confused: isn't this case covered by the
> 
>   rq_lock(rq, &rf);
>   smp_mb__after_spinlock();
> 
> below (all archs)? You meant "before returning to user-space, after
> storing to rq->curr"?

Right, my bad.

> 
> 
>> +	 * Writing to CR3 provides that full memory barrier.
>> +	 */
>>  	if (real_prev == next) {
>>  		VM_BUG_ON(this_cpu_read(cpu_tlbstate.ctxs[prev_asid].ctx_id) !=
>>  			  next->context.ctx_id);
>> diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
>> index df4005e2c4cf..f3bc261fe7c7 100644
>> --- a/include/linux/sched/mm.h
>> +++ b/include/linux/sched/mm.h
>> @@ -38,6 +38,10 @@ static inline void mmgrab(struct mm_struct *mm)
>>  extern void __mmdrop(struct mm_struct *);
>>  static inline void mmdrop(struct mm_struct *mm)
>>  {
>> +	/*
>> +	 * The implicit full barrier implied by atomic_dec_and_test is
>> +	 * required by the membarrier system call.
> 
> "before returning to user-space, after storing to rq->curr", right?

Yes.

I'll send an updated patch to Paul. Thanks for the review!

Mathieu

> 
> (your commit says "on transition from kernel thread _to_ userspace"
> regarding mmdrop()).
> 
>  Andrea
> 
> 
>> +	 */
>>  	if (unlikely(atomic_dec_and_test(&mm->mm_count)))
>>  		__mmdrop(mm);
>>  }
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index c5c1b2c51807..48d524b18868 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -2648,6 +2648,12 @@ static struct rq *finish_task_switch(struct task_struct
>> *prev)
>>  	finish_arch_post_lock_switch();
>>  
>>  	fire_sched_in_preempt_notifiers(current);
>> +	/*
>> +	 * When transitioning from a kernel thread to a userspace
>> +	 * thread, mmdrop()'s implicit full barrier is required by the
>> +	 * membarrier system call, because the current active_mm can
>> +	 * become the current mm without going through switch_mm().
>> +	 */
>>  	if (mm)
>>  		mmdrop(mm);
>>  	if (unlikely(prev_state == TASK_DEAD)) {
>> @@ -3289,6 +3295,9 @@ static void __sched notrace __schedule(bool preempt)
>>  	 * Make sure that signal_pending_state()->signal_pending() below
>>  	 * can't be reordered with __set_current_state(TASK_INTERRUPTIBLE)
>>  	 * done by the caller to avoid the race with signal_wake_up().
>> +	 *
>> +	 * The membarrier system call requires a full memory barrier
>> +	 * after coming from user-space, before storing to rq->curr.
>>  	 */
>>  	rq_lock(rq, &rf);
>>  	smp_mb__after_spinlock();
>> --
>> 2.11.0

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

  reply	other threads:[~2017-09-19 19:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-18 18:01 [PATCH] membarrier: Document scheduler barrier requirements Mathieu Desnoyers
2017-09-18 18:31 ` Paul E. McKenney
2017-09-19  0:26 ` Andrea Parri
2017-09-19 19:56   ` Mathieu Desnoyers [this message]
  -- strict thread matches above, loose matches on Subject: below --
2017-08-17 19:46 Mathieu Desnoyers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1663138547.13906.1505851015752.JavaMail.zimbra@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    --cc=ahh@google.com \
    --cc=avi@scylladb.com \
    --cc=benh@kernel.crashing.org \
    --cc=boqun.feng@gmail.com \
    --cc=davejwatson@fb.com \
    --cc=gromer@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maged.michael@gmail.com \
    --cc=mpe@ellerman.id.au \
    --cc=parri.andrea@gmail.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.