From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752264AbdHAVhA (ORCPT ); Tue, 1 Aug 2017 17:37:00 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:51607 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752012AbdHAVg6 (ORCPT ); Tue, 1 Aug 2017 17:36:58 -0400 Date: Tue, 1 Aug 2017 14:36:52 -0700 From: "Paul E. McKenney" To: Andy Lutomirski Cc: Mathieu Desnoyers , Stephen Rothwell , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Peter Zijlstra , Linux-Next Mailing List , linux-kernel Subject: Re: linux-next: manual merge of the rcu tree with the tip tree Reply-To: paulmck@linux.vnet.ibm.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> <1639218309.1091.1501596152868.JavaMail.zimbra@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17080121-0052-0000-0000-00000248FA29 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007467; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000215; SDB=6.00896175; UDB=6.00448289; IPR=6.00676363; BA=6.00005506; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00016485; XFM=3.00000015; UTC=2017-08-01 21:36:55 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17080121-0053-0000-0000-000051873B63 Message-Id: <20170801213652.GJ3730@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-08-01_13:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708010346 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 01, 2017 at 07:15:40AM -0700, Andy Lutomirski wrote: > On Tue, Aug 1, 2017 at 7:02 AM, Mathieu Desnoyers > 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 > > (it's already there) [A] > > update to rq->curr changing the rq->curr->mm value > > (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? The thing that got my attention was your patch removing the load_cr3(). Ah, looking closer, it appears that you have not eliminated the CR3 load, but just renamed it to write_cr3(). So if there is always still a CR3 load, you are right, I should be able to simply move the comment. Or let you insert the comment into your patch? So there is still always a CR3 load, correct? (Hey, I thought that maybe x86 was moving to ASIDs or some such.) Thanx, Paul