Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2338956imm; Sat, 28 Jul 2018 14:57:23 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfSm5O1eMf4xZy1VUARWLmOXUxZ2XKygx5hZwxyh2xY8/1f62W/i5Rd3c9hzFdz3fwsrS/W X-Received: by 2002:a62:89d8:: with SMTP id n85-v6mr11884185pfk.83.1532815043767; Sat, 28 Jul 2018 14:57:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532815043; cv=none; d=google.com; s=arc-20160816; b=mfklzKRSJzkvVQ0DtdKKQb8JzftcLCflSTfEcsmCjLe0vpwZsuiOKeuF9XQQykB+9t FaWXk7mVmia1YXw0Wfuq8hky+PixVUN1jTzwQsTqTYFxwIm6lO2UomXS6TVEkKrlW57N /+sOqKYBZo6L66rszyJwABD4SCJvkRaA9RK7MK4nyCEEDeZ1YCvVNxl627RImNORLvAE lWaMkO5WSmkUEO1goqAKl3cgNwhETLF8gge9JTA1FdCEA+k6LhUHK2XakktEmXtqn69U vChPGtG2iMGaJHXL7P5fKEi3gjqEPnZ1if/oubCJrUJniwERDFSfTpaMGFY3LO5Anh8B ivJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=DhZ4yD5KAYBVJ8MKmbQWlAnpzOg01FvswnTZ3FDsvSY=; b=utsQNLE+u8RHp93vFDJmUuxbXOqIQOtALm0GV4mO22UPs3ohlQBjtj6ZSqXohuN+NF V7YObEcqfnUdeTgcZQ9HZ653K1rG0PMRbq1wZ2IjGY42zOL7mCTJTPSET9W7R2c7Nm1I 9MLB6zD74U0YQfJN44nKz+RqbWSvoxmJdmH89UuTwWskjf9I1U5kezzoEed4gVWy++kl 7svXxxG9ZXmCc/ig9Pb9Dj5JRmArfpoC5B7N+kcNgWIxEgFVrY4Gq1ZfiTsAfQmkLQF0 qB3gk8Yd6VTWOYolrtuWKG4FxI0WYYnzacM4q65A+NiQHlsKeYKqs0ymr78PlmJhGlqI PjnQ== 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 l18-v6si6871311pgi.249.2018.07.28.14.56.33; Sat, 28 Jul 2018 14:57:23 -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 S1731487AbeG1XWW (ORCPT + 99 others); Sat, 28 Jul 2018 19:22:22 -0400 Received: from shelob.surriel.com ([96.67.55.147]:44206 "EHLO shelob.surriel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731426AbeG1XWV (ORCPT ); Sat, 28 Jul 2018 19:22:21 -0400 Received: from imladris.surriel.com ([96.67.55.152]) by shelob.surriel.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fjXA0-0000QZ-JI; Sat, 28 Jul 2018 17:54:00 -0400 From: Rik van Riel To: linux-kernel@vger.kernel.org Cc: kernel-team@fb.com, peterz@infradead.org, luto@kernel.org, x86@kernel.org, vkuznets@redhat.com, mingo@kernel.org, efault@gmx.de, dave.hansen@intel.com, will.daecon@arm.com, catalin.marinas@arm.com, benh@kernel.crashing.org, Rik van Riel Subject: [PATCH 01/10] x86,tlb: clarify memory barrier in switch_mm_irqs_off Date: Sat, 28 Jul 2018 17:53:48 -0400 Message-Id: <20180728215357.3249-2-riel@surriel.com> X-Mailer: git-send-email 2.14.4 In-Reply-To: <20180728215357.3249-1-riel@surriel.com> References: <20180728215357.3249-1-riel@surriel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Clarify exactly what the memory barrier synchronizes with. Suggested-by: Peter Zijlstra Signed-off-by: Rik van Riel --- arch/x86/mm/tlb.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c index 752dbf4e0e50..5321e02c4e09 100644 --- a/arch/x86/mm/tlb.c +++ b/arch/x86/mm/tlb.c @@ -263,8 +263,11 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next, /* * Read the tlb_gen to check whether a flush is needed. * If the TLB is up to date, just use it. - * The barrier synchronizes with the tlb_gen increment in - * the TLB shootdown code. + * The TLB shootdown code first increments tlb_gen, and then + * sends IPIs to CPUs that have this CPU loaded and are not + * in lazy TLB mode. The barrier ensures we handle + * cpu_tlbstate.is_lazy before tlb_gen, keeping this code + * synchronized with the TLB flush code. */ smp_mb(); next_tlb_gen = atomic64_read(&next->context.tlb_gen); -- 2.14.4