Received: by 10.213.65.68 with SMTP id h4csp448719imn; Fri, 6 Apr 2018 03:11:04 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/jtuHMZIOKCPZIqsBDAxy66FZKHDm30Zh6aKLC9k8weJXnmu1DV9q3zJw0Zuj5QGnqw9qk X-Received: by 10.101.88.78 with SMTP id s14mr3000066pgr.97.1523009464082; Fri, 06 Apr 2018 03:11:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523009464; cv=none; d=google.com; s=arc-20160816; b=Dxl21fj3fvjVwdG3Q5H/SugAxzqyJAnnqI6jt02fXfYnuS8MIDMhAHtFripX5Rd8Ja yMHHEJhv7cX4vc2podMAImrTocvbspyV+VIAtLUMTqIWTPbv2ZGHyA6W2GSmfKvtRFCs tjB5fUuRdWNJndYt0OXA3piMZ7G77hIPN3O3kN9pUbwYDuXbjHJsaRONKWHHqXCRhA8j 4Vm+uSmBpQmDqpYlatjCueLGXjFL7G9Rr73wkyySqksjeVSFNuL20CIQ+emGmuqPIEYb KFx5LeJvJhCM1sbBfVyAos806+8jancSEVFSz+UE7EU2mZck4Fa9RVB8lEWWQzs7PoIK 3jnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=Ymqx3feaoP5HzCCQae39J+KEtudNUEJJ1aUOSSQOkHI=; b=e3BlvGmAX8O1KUemNpeqmM7urbrHK/ui+M82cddE6ilzXlvRAisuybIHa5iCcNIf2U bAxdS9mycDf4cABf/90pTVkkZS4nbdnmQO4DlPXhrttTW3G5g1nDxtGV/FLlioElmupb KvzRqcbsvqRll/25ErKeawhnf5pax1dzIN3odGIaEC1CLnULl1lw2hO28JDm1YTDBlTx 5u8xfzgD9dezzCVa+V7RuK38TNToXsTmXcG2p84y1+HvqNJM5Yz1n4p/IJ/ud5jxwK94 5ydcjLjkViyYTWyFwRMywli6IDwiPhZjMZjXeugyDM3kR4BgiM1fQ1VaGWmYUKXBWlOF z2hw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t22-v6si8738780plj.233.2018.04.06.03.10.50; Fri, 06 Apr 2018 03:11:04 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752054AbeDFKJ3 (ORCPT + 99 others); Fri, 6 Apr 2018 06:09:29 -0400 Received: from foss.arm.com ([217.140.101.70]:34654 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751938AbeDFKJ1 (ORCPT ); Fri, 6 Apr 2018 06:09:27 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3275D15AD; Fri, 6 Apr 2018 03:09:27 -0700 (PDT) Received: from [10.1.207.55] (melchizedek.cambridge.arm.com [10.1.207.55]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 333823F587; Fri, 6 Apr 2018 03:09:23 -0700 (PDT) Subject: Re: [PATCH 3/5] arm64: early ISB at exit from extended quiescent state To: Yury Norov Cc: "Paul E. McKenney" , Mark Rutland , Will Deacon , Chris Metcalf , Christopher Lameter , Russell King - ARM Linux , Steven Rostedt , Mathieu Desnoyers , Catalin Marinas , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Alexey Klimov , linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, kvm-ppc@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20180405171800.5648-1-ynorov@caviumnetworks.com> <20180405171800.5648-4-ynorov@caviumnetworks.com> From: James Morse Message-ID: Date: Fri, 6 Apr 2018 11:06:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180405171800.5648-4-ynorov@caviumnetworks.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Yury, On 05/04/18 18:17, Yury Norov wrote: > This series enables delaying of kernel memory synchronization > for CPUs running in extended quiescent state (EQS) till the exit > of that state. > > ARM64 uses IPI mechanism to notify all cores in SMP system that > kernel text is changed; and IPI handler calls isb() to synchronize. > > If we don't deliver IPI to EQS CPUs anymore, we should add ISB early > in EQS exit path. > > There are 2 such paths. One starts in do_idle() loop, and other > in el0_svc entry. For do_idle(), isb() is added in > arch_cpu_idle_exit() hook. And for SVC handler, isb is called in > el0_svc_naked. (I know nothing about this EQS stuff, but) there is a third path that might be relevant. From include/linux/context_tracking.h:guest_enter_irqoff(): | * KVM does not hold any references to rcu protected data when it | * switches CPU into a guest mode. In fact switching to a guest mode | * is very similar to exiting to userspace from rcu point of view. In | * addition CPU may stay in a guest mode for quite a long time (up to | * one time slice). Lets treat guest mode as quiescent state, just like | * we do with user-mode execution. For non-VHE systems guest_enter_irqoff()() is called just before we jump to EL2. Coming back gives us an exception-return, so we have a context-synchronisation event there, and I assume we will never patch the hyp-text on these systems. But with VHE on the upcoming kernel version we still go on to run code at the same EL. Do we need an ISB on the path back from the guest once we've told RCU we've 'exited user-space'? If this code can be patched, do we have a problem here? > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S > index c8d9ec363ddd..b1e1c19b4432 100644 > --- a/arch/arm64/kernel/entry.S > +++ b/arch/arm64/kernel/entry.S > @@ -48,7 +48,7 @@ > .endm > > .macro el0_svc_restore_syscall_args > -#if defined(CONFIG_CONTEXT_TRACKING) > +#if !defined(CONFIG_TINY_RCU) || defined(CONFIG_CONTEXT_TRACKING) > restore_syscall_args > #endif > .endm > @@ -483,6 +483,19 @@ __bad_stack: > ASM_BUG() > .endm > > +/* > + * If CPU is in extended quiescent state we need isb to ensure that > + * possible change of kernel text is visible by the core. > + */ > + .macro isb_if_eqs > +#ifndef CONFIG_TINY_RCU > + bl rcu_is_watching > + cbnz x0, 1f > + isb // pairs with aarch64_insn_patch_text > +1: > +#endif > + .endm > + > el0_sync_invalid: > inv_entry 0, BAD_SYNC > ENDPROC(el0_sync_invalid) > @@ -949,6 +962,7 @@ alternative_else_nop_endif > > el0_svc_naked: // compat entry point > stp x0, xscno, [sp, #S_ORIG_X0] // save the original x0 and syscall number > + isb_if_eqs > enable_daif > ct_user_exit > el0_svc_restore_syscall_args Shouldn't this be at the point that RCU knows we've exited user-space? Otherwise there is a gap where RCU thinks we're in user-space, we're not, and we're about to tell it. Code-patching occurring in this gap would be missed. This gap only contains 'enable_daif', and any exception that occurs here is safe, but its going to give someone a nasty surprise... Mark points out this ISB needs to be after RCU knows we're not quiescent: https://lkml.org/lkml/2018/4/3/378 Can't this go in the rcu exit-quiescence code? Isn't this what your rcu_dynticks_eqs_exit_sync() hook does? Thanks, James