From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751403AbbEDOVH (ORCPT ); Mon, 4 May 2015 10:21:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42458 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751168AbbEDOVA (ORCPT ); Mon, 4 May 2015 10:21:00 -0400 Message-ID: <55477FDE.8060304@redhat.com> Date: Mon, 04 May 2015 10:19:10 -0400 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Paolo Bonzini , Ingo Molnar , Andy Lutomirski CC: "linux-kernel@vger.kernel.org" , X86 ML , williams@redhat.com, Andrew Lutomirski , fweisbec@redhat.com, Peter Zijlstra , Heiko Carstens , Thomas Gleixner , Ingo Molnar , "Paul E. McKenney" , Linus Torvalds Subject: Re: [PATCH 3/3] context_tracking,x86: remove extraneous irq disable & enable from context tracking on syscall entry References: <554399D1.6010405@redhat.com> <20150501155912.GA451@gmail.com> <20150501162109.GA1091@gmail.com> <5543A94B.3020108@redhat.com> <20150501163431.GB1327@gmail.com> <5543C05E.9040209@redhat.com> <20150501184025.GA2114@gmail.com> <5543CFE5.1030509@redhat.com> <20150502052733.GA9983@gmail.com> <55473B47.6080600@redhat.com> In-Reply-To: <55473B47.6080600@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/04/2015 05:26 AM, Paolo Bonzini wrote: > > > On 02/05/2015 07:27, Ingo Molnar wrote: >> >> - synchronize_rcu() avoids having to send an IPI by taking a >> peak at rq->curr's pt_regs::flag, and if: >> >> - the flag is 0 then it has observed a quiescent state. >> >> - the flag is 1, then it would set TIF_NOHZ and wait for a >> completion from a TIF_NOHZ callback. > > Isn't this racy? > > synchronize_rcu CPU nohz CPU > --------------------------------------------------------- > set flag = 0 > read flag = 0 > return to userspace > set TIF_NOHZ > > and there's no guarantee that TIF_NOHZ is ever processed by the nohz CPU. Actually, the "race" in this direction is fine. If flag==0, then the nohz CPU is not accessing any RCU protected data structures, and the synhcronize_rcu CPU will not be setting TIF_NOHZ. The race is only a concern if the synchronize_rcu CPU reads flag==1 (nohz CPU is in kernel space), and sets TIF_NOHZ after the nohz CPU has cleared flag (and is unable to handle RCU stuff). An atomic compare and swap prevents that issue. The other race, of the synchronize_rcu CPU reading 0, followed by the nohz CPU going into kernel space, and setting the flag to 1, should be fine. After all, this means the nohz_full CPU just went into a new RCU grace period, which is just what the synchronize_rcu CPU was waiting for. -- All rights reversed