From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751952AbdHAOQE (ORCPT <rfc822;w@1wt.eu>);
        Tue, 1 Aug 2017 10:16:04 -0400
Received: from mail.kernel.org ([198.145.29.99]:60588 "EHLO mail.kernel.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751535AbdHAOQD (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 1 Aug 2017 10:16:03 -0400
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9F61322C99
Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org
Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org
MIME-Version: 1.0
In-Reply-To: <1639218309.1091.1501596152868.JavaMail.zimbra@efficios.com>
References: <20170731135029.479025ea@canb.auug.org.au> <20170731161341.GG3730@linux.vnet.ibm.com>
 <1145333348.610.1501545845911.JavaMail.zimbra@efficios.com>
 <20170801040323.GP3730@linux.vnet.ibm.com> <CALCETrWO5g5HuNpxa4Phxg--fDPWpuCVDTVr-UfuzrK5wn-8dQ@mail.gmail.com>
 <1639218309.1091.1501596152868.JavaMail.zimbra@efficios.com>
From: Andy Lutomirski <luto@kernel.org>
Date: Tue, 1 Aug 2017 07:15:40 -0700
X-Gmail-Original-Message-ID: <CALCETrWWx8h=74td8bxbR6KZJN2GLAZ_jz9G-x9Q+Vn2AHSijQ@mail.gmail.com>
Message-ID: <CALCETrWWx8h=74td8bxbR6KZJN2GLAZ_jz9G-x9Q+Vn2AHSijQ@mail.gmail.com>
Subject: Re: linux-next: manual merge of the rcu tree with the tip tree
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Andy Lutomirski <luto@kernel.org>,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        Stephen Rothwell <sfr@canb.auug.org.au>,
        Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Linux-Next Mailing List <linux-next@vger.kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Aug 1, 2017 at 7:02 AM, Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> wrote:
> /*
>  * The full memory barrier implied by mm_cpumask update operations
>  * is required by the membarrier system call.
>  */
>
> What we want to order here is:
>
> prev userspace memory accesses
> schedule
>   <full mb> (it's already there) [A]
>   update to rq->curr changing the rq->curr->mm value
>   <full mb> (provided by mm_cpumask updates in switch_mm on x86) [B]

If I understand this right, the issue with relying on CR3 writes is
that the target CPU could switch to a kernel thread and back to the
same user mm white the membarrier caller is reading its mm, right?