Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1826321imm; Mon, 3 Sep 2018 10:26:04 -0700 (PDT) X-Google-Smtp-Source: ANB0VdY0djU1Bqwm6AJ3E/pYjnnNva5emHAWvjMV46s+qV99Eel2r2mXaWLiTHvbUIGPNd2JvV9h X-Received: by 2002:a63:5419:: with SMTP id i25-v6mr25366616pgb.345.1535995564887; Mon, 03 Sep 2018 10:26:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535995564; cv=none; d=google.com; s=arc-20160816; b=XKhYKo/5kYwfnrgFEGa6VURT8OxMwdLBafUdxHdBPZ1vV+KUaCh99qI4bqfNeXQ3y0 D2U+Kr1yAqg3pRmFFOnEewXXxbK8MRGFRzuock73m2YCp5ZG1y/1w8UA1mCdBx/ufvll jZF1SzyqLSm4HUtuWEpN38oib3Ouy0lyMe7TfJNlckNLEOMdHohTO9/DfmdTvmFKOaSi wgI5w4giPVf28f+Od3QQC/b3yvGxDeGz7ZB5ftPnlB5GzZo6GVsiVK8gTq8iGMus0lyi gBM3wXZnq1VdUrQj3gICsOCTBkxYUFoSb4Hx4jU87fFYPynbCifmAB3MOETtUmYxOSOe xFIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=dvPdUXSfXmV3waZbL4/ubC2CEIotX12sSzxUXpuvDa8=; b=zGJsza2b0Hkb77OQbs8PXd6PEba75FTqcNJWqAua7Zg3nwpsxSgPW+32ifNxH2F5/1 nYY5JYqJKgxxDP2bc4h5RQqQxZm2W1VlWHBJL8fQZubIY4dU1FLxN6IXp5m+0IiXnDdf kXwWpqmNMx4N2BKaGH6TjCs0MhsD3GoNENrzUUE09V836vZ1F6gSJM62mjwwhNG+r6TC /KIVRlDqJBnByVwOrq8aG1ovFOWfhnGutiGQ2uEtSIgNBV+9Tclvg2aR/IkNFUxvPyva xlcBdzPbaJRPmzfAHTb3/vMtrxgWS0O9bV4G3GWuepg/N9lY36mnx7VUG/qElT6ZWWJO LATA== 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 e39-v6si18811599plg.386.2018.09.03.10.25.49; Mon, 03 Sep 2018 10:26: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 S1730568AbeICVpx (ORCPT + 99 others); Mon, 3 Sep 2018 17:45:53 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:45574 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730190AbeICVpv (ORCPT ); Mon, 3 Sep 2018 17:45:51 -0400 Received: from localhost (ip-213-127-74-90.ip.prioritytelecom.net [213.127.74.90]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 350A3D2F; Mon, 3 Sep 2018 17:24:44 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jann Horn , "Peter Zijlstra (Intel)" , Rik van Riel , Nicholas Piggin , David Miller , Will Deacon , Martin Schwidefsky , Michael Ellerman , stable@kernel.org, Linus Torvalds Subject: [PATCH 4.14 110/165] mm/tlb, x86/mm: Support invalidating TLB caches for RCU_TABLE_FREE Date: Mon, 3 Sep 2018 18:56:36 +0200 Message-Id: <20180903165701.034109344@linuxfoundation.org> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20180903165655.003605184@linuxfoundation.org> References: <20180903165655.003605184@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Peter Zijlstra commit d86564a2f085b79ec046a5cba90188e612352806 upstream. Jann reported that x86 was missing required TLB invalidates when he hit the !*batch slow path in tlb_remove_table(). This is indeed the case; RCU_TABLE_FREE does not provide TLB (cache) invalidates, the PowerPC-hash where this code originated and the Sparc-hash where this was subsequently used did not need that. ARM which later used this put an explicit TLB invalidate in their __p*_free_tlb() functions, and PowerPC-radix followed that example. But when we hooked up x86 we failed to consider this. Fix this by (optionally) hooking tlb_remove_table() into the TLB invalidate code. NOTE: s390 was also needing something like this and might now be able to use the generic code again. [ Modified to be on top of Nick's cleanups, which simplified this patch now that tlb_flush_mmu_tlbonly() really only flushes the TLB - Linus ] Fixes: 9e52fc2b50de ("x86/mm: Enable RCU based page table freeing (CONFIG_HAVE_RCU_TABLE_FREE=y)") Reported-by: Jann Horn Signed-off-by: Peter Zijlstra (Intel) Acked-by: Rik van Riel Cc: Nicholas Piggin Cc: David Miller Cc: Will Deacon Cc: Martin Schwidefsky Cc: Michael Ellerman Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- arch/Kconfig | 3 +++ arch/x86/Kconfig | 1 + mm/memory.c | 18 ++++++++++++++++++ 3 files changed, 22 insertions(+) --- a/arch/Kconfig +++ b/arch/Kconfig @@ -336,6 +336,9 @@ config HAVE_ARCH_JUMP_LABEL config HAVE_RCU_TABLE_FREE bool +config HAVE_RCU_TABLE_INVALIDATE + bool + config ARCH_HAVE_NMI_SAFE_CMPXCHG bool --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -170,6 +170,7 @@ config X86 select HAVE_PERF_REGS select HAVE_PERF_USER_STACK_DUMP select HAVE_RCU_TABLE_FREE + select HAVE_RCU_TABLE_INVALIDATE if HAVE_RCU_TABLE_FREE select HAVE_REGS_AND_STACK_ACCESS_API select HAVE_RELIABLE_STACKTRACE if X86_64 && UNWINDER_FRAME_POINTER && STACK_VALIDATION select HAVE_STACK_VALIDATION if X86_64 --- a/mm/memory.c +++ b/mm/memory.c @@ -331,6 +331,21 @@ bool __tlb_remove_page_size(struct mmu_g * See the comment near struct mmu_table_batch. */ +/* + * If we want tlb_remove_table() to imply TLB invalidates. + */ +static inline void tlb_table_invalidate(struct mmu_gather *tlb) +{ +#ifdef CONFIG_HAVE_RCU_TABLE_INVALIDATE + /* + * Invalidate page-table caches used by hardware walkers. Then we still + * need to RCU-sched wait while freeing the pages because software + * walkers can still be in-flight. + */ + tlb_flush_mmu_tlbonly(tlb); +#endif +} + static void tlb_remove_table_smp_sync(void *arg) { /* Simply deliver the interrupt */ @@ -367,6 +382,7 @@ void tlb_table_flush(struct mmu_gather * struct mmu_table_batch **batch = &tlb->batch; if (*batch) { + tlb_table_invalidate(tlb); call_rcu_sched(&(*batch)->rcu, tlb_remove_table_rcu); *batch = NULL; } @@ -388,11 +404,13 @@ void tlb_remove_table(struct mmu_gather if (*batch == NULL) { *batch = (struct mmu_table_batch *)__get_free_page(GFP_NOWAIT | __GFP_NOWARN); if (*batch == NULL) { + tlb_table_invalidate(tlb); tlb_remove_table_one(table); return; } (*batch)->nr = 0; } + (*batch)->tables[(*batch)->nr++] = table; if ((*batch)->nr == MAX_TABLE_BATCH) tlb_table_flush(tlb);