From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754534AbcFPQnK (ORCPT <rfc822;w@1wt.eu>);
	Thu, 16 Jun 2016 12:43:10 -0400
Received: from mail-pf0-f196.google.com ([209.85.192.196]:34230 "EHLO
	mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753840AbcFPQnI convert rfc822-to-8bit (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 16 Jun 2016 12:43:08 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: [PATCH v3] Linux VM workaround for Knights Landing A/D leak
From: Nadav Amit <nadav.amit@gmail.com>
In-Reply-To: <1466090042-30908-1-git-send-email-lukasz.anaczkowski@intel.com>
Date: Thu, 16 Jun 2016 09:43:01 -0700
Cc: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Dave Hansen <dave.hansen@linux.intel.com>, ak@linux.intel.com,
        kirill.shutemov@linux.intel.com, mhocko@suse.com,
        akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
        linux-mm@kvack.org, harish.srinivasappa@intel.com,
        lukasz.odzioba@intel.com, grzegorz.andrejczuk@intel.com,
        lukasz.daniluk@intel.com
Content-Transfer-Encoding: 8BIT
Message-Id: <6128C99E-3FAA-4925-B68C-16B36178E00B@gmail.com>
References: <1465923672-14232-1-git-send-email-lukasz.anaczkowski@intel.com> <1466090042-30908-1-git-send-email-lukasz.anaczkowski@intel.com>
To: Lukasz Anaczkowski <lukasz.anaczkowski@intel.com>
X-Mailer: Apple Mail (2.3124)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


Lukasz Anaczkowski <lukasz.anaczkowski@intel.com> wrote:

> From: Andi Kleen <ak@linux.intel.com>
> 
> +void fix_pte_leak(struct mm_struct *mm, unsigned long addr, pte_t *ptep)
> +{
> +	if (cpumask_any_but(mm_cpumask(mm), smp_processor_id()) < nr_cpu_ids) {
> +		trace_tlb_flush(TLB_LOCAL_SHOOTDOWN, TLB_FLUSH_ALL);
This tracing seems incorrect since you don’t perform a local flush.
I don’t think you need any tracing - native_flush_tlb_others will do it for you.

> +		flush_tlb_others(mm_cpumask(mm), mm, addr,
> +				 addr + PAGE_SIZE);
> +		mb();
Why do you need the memory barrier?

Regards,
Nadav