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 S1752138AbcGABz1 (ORCPT <rfc822;w@1wt.eu>);
	Thu, 30 Jun 2016 21:55:27 -0400
Received: from www.sr71.net ([198.145.64.142]:38333 "EHLO blackbird.sr71.net"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751938AbcGABzC (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 30 Jun 2016 21:55:02 -0400
Subject: Re: [PATCH 6/6] x86: Fix stray A/D bit setting into non-present PTEs
To: Nadav Amit <nadav.amit@gmail.com>
References: <20160701001209.7DA24D1C@viggo.jf.intel.com>
 <20160701001218.3D316260@viggo.jf.intel.com>
 <5A585093-4E0D-49BC-A9CA-0072BB83A71C@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>, x86@kernel.org, linux-mm@kvack.org,
        torvalds@linux-foundation.org, akpm@linux-foundation.org, bp@alien8.de,
        ak@linux.intel.com, mhocko@suse.com, dave.hansen@linux.intel.com
From: Dave Hansen <dave@sr71.net>
Message-ID: <5775CD73.2070809@sr71.net>
Date: Thu, 30 Jun 2016 18:54:59 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <5A585093-4E0D-49BC-A9CA-0072BB83A71C@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 06/30/2016 06:50 PM, Nadav Amit wrote:
> Dave Hansen <dave@sr71.net> wrote:
>> +pte_t ptep_clear_flush(struct vm_area_struct *vma, unsigned long address,
>> +		       pte_t *ptep)
>> +{
>> +	struct mm_struct *mm = vma->vm_mm;
>> +	pte_t pte;
>> +
>> +	pte = ptep_get_and_clear(mm, address, ptep);
>> +	if (pte_accessible(mm, pte)) {
>> +		flush_tlb_page(vma, address);
>> +		/*
>> +		 * Ensure that the compiler orders our set_pte()
>> +		 * after the flush_tlb_page() no matter what.
>> +		 */
>> +		barrier();
> 
> I don’t think such a barrier (after remote TLB flush) is needed.
> Eventually, if a remote flush takes place, you get csd_lock_wait() to be
> called, and then smp_rmb() is called (which is essentially a barrier()
> call on x86).

Andi really wanted to make sure this got in here.  He said there was a
bug that bit him really badly once where a function got reordered.
Granted, a call _should_ be sufficient to keep the compiler from
reordering things, but this makes double sure.