From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=79yC=X2=kvack.org=owner-linux-mm@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no
	version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 4BD89C352AA
	for <linux-mm@archiver.kernel.org>; Tue,  1 Oct 2019 22:31:57 +0000 (UTC)
Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17])
	by mail.kernel.org (Postfix) with ESMTP id F09492133F
	for <linux-mm@archiver.kernel.org>; Tue,  1 Oct 2019 22:31:56 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=pass (2048-bit key) header.d=nvidia.com header.i=@nvidia.com header.b="F5pOFyE6"
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F09492133F
Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=nvidia.com
Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org
Received: by kanga.kvack.org (Postfix)
	id A5B398E0005; Tue,  1 Oct 2019 18:31:55 -0400 (EDT)
Received: by kanga.kvack.org (Postfix, from userid 40)
	id A0BDF8E0001; Tue,  1 Oct 2019 18:31:55 -0400 (EDT)
X-Delivered-To: int-list-linux-mm@kvack.org
Received: by kanga.kvack.org (Postfix, from userid 63042)
	id 8FB5F8E0005; Tue,  1 Oct 2019 18:31:55 -0400 (EDT)
X-Delivered-To: linux-mm@kvack.org
Received: from forelay.hostedemail.com (smtprelay0166.hostedemail.com [216.40.44.166])
	by kanga.kvack.org (Postfix) with ESMTP id 6C3668E0001
	for <linux-mm@kvack.org>; Tue,  1 Oct 2019 18:31:55 -0400 (EDT)
Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251])
	by forelay05.hostedemail.com (Postfix) with SMTP id ED68E181AC9B4
	for <linux-mm@kvack.org>; Tue,  1 Oct 2019 22:31:54 +0000 (UTC)
X-FDA: 75996664548.06.mint66_10a137b2ee54b
X-HE-Tag: mint66_10a137b2ee54b
X-Filterd-Recvd-Size: 7436
Received: from hqemgate14.nvidia.com (hqemgate14.nvidia.com [216.228.121.143])
	by imf02.hostedemail.com (Postfix) with ESMTP
	for <linux-mm@kvack.org>; Tue,  1 Oct 2019 22:31:54 +0000 (UTC)
Received: from hqpgpgate102.nvidia.com (Not Verified[216.228.121.13]) by hqemgate14.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA)
	id <B5d93d3db0000>; Tue, 01 Oct 2019 15:31:55 -0700
Received: from hqmail.nvidia.com ([172.20.161.6])
  by hqpgpgate102.nvidia.com (PGP Universal service);
  Tue, 01 Oct 2019 15:31:52 -0700
X-PGP-Universal: processed;
	by hqpgpgate102.nvidia.com on Tue, 01 Oct 2019 15:31:52 -0700
Received: from DRHQMAIL107.nvidia.com (10.27.9.16) by HQMAIL111.nvidia.com
 (172.20.187.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 1 Oct
 2019 22:31:52 +0000
Received: from [10.110.48.28] (10.124.1.5) by DRHQMAIL107.nvidia.com
 (10.27.9.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 1 Oct 2019
 22:31:51 +0000
Subject: Re: [PATCH v3 3/4] mm: don't expose non-hugetlb page to fast gup
 prematurely
To: Yu Zhao <yuzhao@google.com>
CC: "Kirill A. Shutemov" <kirill@shutemov.name>, Peter Zijlstra
	<peterz@infradead.org>, Andrew Morton <akpm@linux-foundation.org>, "Michal
 Hocko" <mhocko@suse.com>, "Kirill A . Shutemov"
	<kirill.shutemov@linux.intel.com>, Ingo Molnar <mingo@redhat.com>, "Arnaldo
 Carvalho de Melo" <acme@kernel.org>, Alexander Shishkin
	<alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@redhat.com>, "Namhyung
 Kim" <namhyung@kernel.org>, Vlastimil Babka <vbabka@suse.cz>, Hugh Dickins
	<hughd@google.com>, =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= <jglisse@redhat.com>,
	Andrea Arcangeli <aarcange@redhat.com>, "Aneesh Kumar K . V"
	<aneesh.kumar@linux.ibm.com>, David Rientjes <rientjes@google.com>, "Matthew
 Wilcox" <willy@infradead.org>, Lance Roy <ldr709@gmail.com>, Ralph Campbell
	<rcampbell@nvidia.com>, Jason Gunthorpe <jgg@ziepe.ca>, Dave Airlie
	<airlied@redhat.com>, Thomas Hellstrom <thellstrom@vmware.com>, "Souptick
 Joarder" <jrdr.linux@gmail.com>, Mel Gorman <mgorman@suse.de>, Jan Kara
	<jack@suse.cz>, Mike Kravetz <mike.kravetz@oracle.com>, Huang Ying
	<ying.huang@intel.com>, Aaron Lu <ziqian.lzq@antfin.com>, Omar Sandoval
	<osandov@fb.com>, Thomas Gleixner <tglx@linutronix.de>, "Vineeth Remanan
 Pillai" <vpillai@digitalocean.com>, Daniel Jordan
	<daniel.m.jordan@oracle.com>, Mike Rapoport <rppt@linux.ibm.com>, "Joel
 Fernandes" <joel@joelfernandes.org>, Mark Rutland <mark.rutland@arm.com>,
	Alexander Duyck <alexander.h.duyck@linux.intel.com>, Pavel Tatashin
	<pavel.tatashin@microsoft.com>, David Hildenbrand <david@redhat.com>,
	"Juergen Gross" <jgross@suse.com>, Anthony Yznaga
	<anthony.yznaga@oracle.com>, "Johannes Weiner" <hannes@cmpxchg.org>, "Darrick
 J . Wong" <darrick.wong@oracle.com>, <linux-kernel@vger.kernel.org>,
	<linux-mm@kvack.org>
References: <20190914070518.112954-1-yuzhao@google.com>
 <20190924232459.214097-1-yuzhao@google.com>
 <20190924232459.214097-3-yuzhao@google.com>
 <20190925082530.GD4536@hirez.programming.kicks-ass.net>
 <20190925222654.GA180125@google.com> <20190926102036.od2wamdx2s7uznvq@box>
 <9465df76-0229-1b44-5646-5cced1bc1718@nvidia.com>
 <20190927050648.GA92494@google.com>
From: John Hubbard <jhubbard@nvidia.com>
X-Nvconfidentiality: public
Message-ID: <712513fe-f064-c965-d165-80d43cfc606f@nvidia.com>
Date: Tue, 1 Oct 2019 15:31:51 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <20190927050648.GA92494@google.com>
X-Originating-IP: [10.124.1.5]
X-ClientProxiedBy: HQMAIL105.nvidia.com (172.20.187.12) To
 DRHQMAIL107.nvidia.com (10.27.9.16)
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1;
	t=1569969115; bh=Fm4rmytUffSMlrMJvqCNwfgP66M6ZLzlK00V/CpJFFs=;
	h=X-PGP-Universal:Subject:To:CC:References:From:X-Nvconfidentiality:
	 Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:
	 X-Originating-IP:X-ClientProxiedBy:Content-Type:Content-Language:
	 Content-Transfer-Encoding;
	b=F5pOFyE6URbV2dqBXw++2yHXCpMGDtvgR/dgEAlUoPavTEAXmwXKH93N2x71r9SSo
	 Jss0dalQenQfu5etmeuoHUZ4graKJ5zyT/NDfaqmXm57r76sohufZvMOSP5s08kmBG
	 zUSz8pwbVQSza3hQjGGsk+ET1gLeUOig3XpXh/htqtMh0X7ZjiNa280eA7a4+4mIo5
	 dD7qA51G0CxWudcKCC+r/8GmJebKhO4XB7gTFqXHCMh8SSybPHxeTPaVR5rOs7KZKD
	 lu9hZXVWc0+sXi53rMywJxReteQYQ7rddDTY7GYrIcgtwQCdvP4ZSxPbsWKhmkjryM
	 TJK6D1oCVo49w==
X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4
Sender: owner-linux-mm@kvack.org
Precedence: bulk
X-Loop: owner-majordomo@kvack.org
List-ID: <linux-mm.kvack.org>

On 9/26/19 10:06 PM, Yu Zhao wrote:
> On Thu, Sep 26, 2019 at 08:26:46PM -0700, John Hubbard wrote:
>> On 9/26/19 3:20 AM, Kirill A. Shutemov wrote:
>>> On Wed, Sep 25, 2019 at 04:26:54PM -0600, Yu Zhao wrote:
>>>> On Wed, Sep 25, 2019 at 10:25:30AM +0200, Peter Zijlstra wrote:
>>>>> On Tue, Sep 24, 2019 at 05:24:58PM -0600, Yu Zhao wrote:
>> ...
>>>>> I'm thinking this patch make stuff rather fragile.. Should we instead
>>>>> stick the barrier in set_p*d_at() instead? Or rather, make that store a
>>>>> store-release?
>>>>
>>>> I prefer it this way too, but I suspected the majority would be
>>>> concerned with the performance implications, especially those
>>>> looping set_pte_at()s in mm/huge_memory.c.
>>>
>>> We can rename current set_pte_at() to __set_pte_at() or something and
>>> leave it in places where barrier is not needed. The new set_pte_at()( will
>>> be used in the rest of the places with the barrier inside.
>>
>> +1, sounds nice. I was unhappy about the wide-ranging changes that would have
>> to be maintained. So this seems much better.
> 
> Just to be clear that doing so will add unnecessary barriers to one
> of the two paths that share set_pte_at().

Good point, maybe there's a better place to do it...


> 
>>> BTW, have you looked at other levels of page table hierarchy. Do we have
>>> the same issue for PMD/PUD/... pages?
>>>
>>
>> Along the lines of "what other memory barriers might be missing for
>> get_user_pages_fast(), I'm also concerned that the synchronization between
>> get_user_pages_fast() and freeing the page tables might be technically broken,
>> due to missing memory barriers on the get_user_pages_fast() side. Details:
>>
>> gup_fast() disables interrupts, but I think it also needs some sort of
>> memory barrier(s), in order to prevent reads of the page table (gup_pgd_range,
>> etc) from speculatively happening before the interrupts are disabled. 
> 
> I was under impression switching back from interrupt context is a
> full barrier (otherwise wouldn't we be vulnerable to some side
> channel attacks?), so the reader side wouldn't need explicit rmb.
> 

Documentation/memory-barriers.txt points out:

INTERRUPT DISABLING FUNCTIONS
-----------------------------

Functions that disable interrupts (ACQUIRE equivalent) and enable interrupts
(RELEASE equivalent) will act as compiler barriers only.  So if memory or I/O
barriers are required in such a situation, they must be provided from some
other means.

btw, I'm really sorry I missed your responses over the last 3 or 4 days.
I just tracked down something in our email system that was sometimes
moving some emails to spam (just few enough to escape immediate attention, argghh!).
I think I killed it off for good now. I wasn't ignoring you. :)


thanks,
-- 
John Hubbard
NVIDIA