Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp129574pxu; Thu, 22 Oct 2020 17:53:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzPyGYp2t1f69MpdXzkIzZcdC+KxD/lco09Ypedwe+NjfnWmhIL/Srg/OCZQ2PiqH5LJx+w X-Received: by 2002:a17:906:38d8:: with SMTP id r24mr5068817ejd.32.1603414395333; Thu, 22 Oct 2020 17:53:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603414395; cv=none; d=google.com; s=arc-20160816; b=MPMZSHyfV66RL5FoAwpU82wU01C7C6BjWzxhRA5edZWfpU96B4e6nKlDxKZqOihv9W Y0UShNkrdzkmWkVW2sb6WTTCwW1mVNChTKzoo2tkx4/X04KcquZjbH8ko5qkVeV78Cr1 sYErrXTnIInIKNdrngPunr65Jx2ic/JukIxkPa/3zNciniw6lJhRXghtp75OnMFjGVe9 911XQijfkWRTj5Al3an87lJaAEwvOnhjR+mAgX8ZFRQC9lMWn3ZqU6SM1PsCDGZdpfUl Qi+aGrgn22JpK0UfNYy6YmW27x8+y81sF0WkAF0RplPx2vmY2fhzaSZBQYygxbR6ZZsb 1UiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=eVItXkL1JLXbyeJqJGRNhXfqfEg0ptT6nXNRxtfWxa0=; b=CiGq3Wnu4SVKbsAPwHL7/qBxJSlQyu97J6prE75q1RqPEaLYam0PRbmWQa0tjXbtkt SoMNo/+4vZiU2mSujJpnymxbkdkuw2Kt5I4P39z08X3Sw1L9idEwik0e7camvC86U8c3 X+/Ckrg7SEg0E/T4OBMtjyBDCNsCd7yutpLs9TPQNJUWaS0QGxr5JlXsgd74FlttMAyi JnUGF4/W+Hn92Q1b6IbWqBLriFgYaCE2/bTZFTNGtX8WqReNItrbJczECW+UmnNkTZ/o 3xwJkDqRy04SQqc6J31hnN3mAW/gryPZt9x2dKByRsjiUN/6SFOltwD5LcZA0YFtJltH 9rWg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=uBOvMYuK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x1si1896184ede.408.2020.10.22.17.52.52; Thu, 22 Oct 2020 17:53:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=uBOvMYuK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2900876AbgJVRuy (ORCPT + 99 others); Thu, 22 Oct 2020 13:50:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36518 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2508341AbgJVRuy (ORCPT ); Thu, 22 Oct 2020 13:50:54 -0400 Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C078EC0613CF for ; Thu, 22 Oct 2020 10:50:53 -0700 (PDT) Received: by mail-wm1-x342.google.com with SMTP id c194so3176414wme.2 for ; Thu, 22 Oct 2020 10:50:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eVItXkL1JLXbyeJqJGRNhXfqfEg0ptT6nXNRxtfWxa0=; b=uBOvMYuKqG0FmnBNcmwnEIjVX9ZWYn6/V3Q+JkV0uQ4jD2H0eRa8UZr5RngEY/lGVU TxpCz9tVOXdbNEXOpvuuhexVoTvHnnw57wBjYCeYqMnSUbET6eHaGWsr4f/G9OtCnzZL 9in6oLGAIQ2NhngHDk9FKAorm6E4FJCWL0sJiMFr1j3H8IV8EA7gXy81orJk1S/Lg85w EwtkkSJYCrDHUBDqlpq6BNTTuumV9XIiRmcVW82jvggBwCnfNcVpFT6QetpeHWZb8n6f XmVevVZzrBh6Uj1riTk13Ye8kwwzTEFQZQ8bf4OYrH5i+EvbgdG/s/qHWkSZNR3iOaju utOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eVItXkL1JLXbyeJqJGRNhXfqfEg0ptT6nXNRxtfWxa0=; b=Z+sqbpwnPDeqYaNsHPusByfY7lsbfoB/NlmQAbeZtsM2m8cvZA2nBrpdwASKDx28JR iQf1xkGUNrdFS0q6MAGZFeo9wxbJpKs8IENF7rgpBcjX8UgSvvQpXJjtVgGB30BMuZdB Rkci8QLKSlB+6pk0nPVABbmMZx6VxjkVQej1+n2CldfHuS4RSFPSUIOFI3TxeBj9WrKG WwDGO4m01m92MWCNLM+4m4p0Nz2387iORcH3wPxIhynMW1TYEaQxzkaCeSkNEynUs/+D ZnC3iu3DM2AraXZgmUeN1t3ydBgguf7CHIH/H988EdRcXrablbY/3PdEf54tG1MEiog/ bC1A== X-Gm-Message-State: AOAM531pFge+N7thbSnuqWDRwD7F7TYDqbg8OiLI1OGGFHPgfqI49ILb bATbLoJr6GMcHmAGxHQGbfnQghaSq+S9lmGBmUK5l/M7Auo= X-Received: by 2002:a05:600c:2256:: with SMTP id a22mr3644551wmm.138.1603389052121; Thu, 22 Oct 2020 10:50:52 -0700 (PDT) MIME-Version: 1.0 References: <20201009144225.12019-1-jgross@suse.com> <160336379724.7002.17024152211307266195.tip-bot2@tip-bot2> In-Reply-To: <160336379724.7002.17024152211307266195.tip-bot2@tip-bot2> From: Andy Lutomirski Date: Thu, 22 Oct 2020 10:50:40 -0700 Message-ID: Subject: Re: [tip: x86/urgent] x86/alternative: Don't call text_poke() in lazy TLB mode To: LKML Cc: linux-tip-commits@vger.kernel.org, Juergen Gross , "Peter Zijlstra (Intel)" , x86 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 22, 2020 at 3:50 AM tip-bot2 for Juergen Gross wrote: > > The following commit has been merged into the x86/urgent branch of tip: > > Commit-ID: abee7c494d8c41bb388839bccc47e06247f0d7de > Gitweb: https://git.kernel.org/tip/abee7c494d8c41bb388839bccc47e06247f0d7de > Author: Juergen Gross > AuthorDate: Fri, 09 Oct 2020 16:42:25 +02:00 > Committer: Peter Zijlstra > CommitterDate: Thu, 22 Oct 2020 12:37:23 +02:00 > > x86/alternative: Don't call text_poke() in lazy TLB mode > > When running in lazy TLB mode the currently active page tables might > be the ones of a previous process, e.g. when running a kernel thread. > > This can be problematic in case kernel code is being modified via > text_poke() in a kernel thread, and on another processor exit_mmap() > is active for the process which was running on the first cpu before > the kernel thread. > > As text_poke() is using a temporary address space and the former > address space (obtained via cpu_tlbstate.loaded_mm) is restored > afterwards, there is a race possible in case the cpu on which > exit_mmap() is running wants to make sure there are no stale > references to that address space on any cpu active (this e.g. is > required when running as a Xen PV guest, where this problem has been > observed and analyzed). > > In order to avoid that, drop off TLB lazy mode before switching to the > temporary address space. Now that I'm actually awake: Acked-by: Andy Lutomirski although it might be nice to at least have a comment that there's some performance being left on the table. PeterZ, I like your version except that, if we do that, I also think we should move this whole mess into tlb.c instead of alternative.c. --Andy > > Fixes: cefa929c034eb5d ("x86/mm: Introduce temporary mm structs") > Signed-off-by: Juergen Gross > Signed-off-by: Peter Zijlstra (Intel) > Link: https://lkml.kernel.org/r/20201009144225.12019-1-jgross@suse.com > --- > arch/x86/kernel/alternative.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c > index cdaab30..cd6be6f 100644 > --- a/arch/x86/kernel/alternative.c > +++ b/arch/x86/kernel/alternative.c > @@ -807,6 +807,15 @@ static inline temp_mm_state_t use_temporary_mm(struct mm_struct *mm) > temp_mm_state_t temp_state; > > lockdep_assert_irqs_disabled(); > + > + /* > + * Make sure not to be in TLB lazy mode, as otherwise we'll end up > + * with a stale address space WITHOUT being in lazy mode after > + * restoring the previous mm. > + */ > + if (this_cpu_read(cpu_tlbstate.is_lazy)) > + leave_mm(smp_processor_id()); > + > temp_state.mm = this_cpu_read(cpu_tlbstate.loaded_mm); > switch_mm_irqs_off(NULL, mm, current); > -- Andy Lutomirski AMA Capital Management, LLC