From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 48114C4CECF for ; Mon, 23 Sep 2019 19:58:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E5C14206C2 for ; Mon, 23 Sep 2019 19:58:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=nvidia.com header.i=@nvidia.com header.b="osa+rcGi" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E5C14206C2 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 640BE6B0270; Mon, 23 Sep 2019 15:58:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F1846B0272; Mon, 23 Sep 2019 15:58:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E0696B0273; Mon, 23 Sep 2019 15:58:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0020.hostedemail.com [216.40.44.20]) by kanga.kvack.org (Postfix) with ESMTP id 2DB0E6B0270 for ; Mon, 23 Sep 2019 15:58:36 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id C6C998133 for ; Mon, 23 Sep 2019 19:58:35 +0000 (UTC) X-FDA: 75967247790.09.ink77_68089c942e05a X-HE-Tag: ink77_68089c942e05a X-Filterd-Recvd-Size: 6859 Received: from hqemgate14.nvidia.com (hqemgate14.nvidia.com [216.228.121.143]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Mon, 23 Sep 2019 19:58:34 +0000 (UTC) Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqemgate14.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Mon, 23 Sep 2019 12:58:35 -0700 Received: from hqmail.nvidia.com ([172.20.161.6]) by hqpgpgate101.nvidia.com (PGP Universal service); Mon, 23 Sep 2019 12:58:33 -0700 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Mon, 23 Sep 2019 12:58:33 -0700 Received: from DRHQMAIL107.nvidia.com (10.27.9.16) by HQMAIL105.nvidia.com (172.20.187.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 23 Sep 2019 19:58:32 +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; Mon, 23 Sep 2019 19:58:32 +0000 Subject: Re: [PATCH v2 11/11] powerpc/mm/book3s64/pgtable: Uses counting method to skip serializing To: Leonardo Bras , , , Linux-MM CC: Arnd Bergmann , Richard Fontana , "Greg Kroah-Hartman" , YueHaibing , Nicholas Piggin , Mike Rapoport , Keith Busch , Jason Gunthorpe , Paul Mackerras , Aneesh Kumar K.V , Allison Randal , "Mahesh Salgaonkar" , Ganesh Goudar , Thomas Gleixner , Ira Weiny , Andrew Morton , "Dan Williams" References: <20190920195047.7703-1-leonardo@linux.ibm.com> <20190920195047.7703-12-leonardo@linux.ibm.com> <1b39eaa7-751d-40bc-d3d7-41aaa15be42a@nvidia.com> <24863d8904c6e05e5dd48cab57db4274675ae654.camel@linux.ibm.com> <4ea26ffb-ad03-bdff-7893-95332b22a5fd@nvidia.com> <18c5c378db98f223a0663034baa9fd6ce42f1ec7.camel@linux.ibm.com> <8706a1f1-0c5e-d152-938b-f355b9a5aaa8@nvidia.com> From: John Hubbard X-Nvconfidentiality: public Message-ID: <1568b3ef-cec9-bf47-edaa-c775c2f544fb@nvidia.com> Date: Mon, 23 Sep 2019 12:58:32 -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: 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=1569268715; bh=CxkbhkWcB0j6c0hQrI2IlVzjpcve7G3EFL8ljZ1vsNg=; 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=osa+rcGip1BlR1iL7c0QG8GAU1Q8EJYM+7MKE/2olTGatfWy6QATer+Vot5N8zClu OGJxjGWL2oUJk82XhQw67UpnBnRdqkR6F4aribTrgHpCO92lOnAlzbCXuleE356gIh IWDqD4G452uLukRDW63ppnqze24PNK3zn8n34vY4tjpENFtmtWFDJfK5CiIbmi7CZk g+zeFkMtiHAHij0NIlIKnp3c2FClSvSXcy+kpK2+mcm3T5CmrjGT8qTvp+TPzkNRTS Bx9+BmEtrGJyFXfCRUX90uLEDnNP2pV+5AwXSXB5nrTZ3266YLU1CsctCzFvLmiFpm 9HYUFKTZxuThg== 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: On 9/23/19 12:40 PM, Leonardo Bras wrote: > On Mon, 2019-09-23 at 11:14 -0700, John Hubbard wrote: >> On 9/23/19 10:25 AM, Leonardo Bras wrote: >> [...] >> That part is all fine, but there are no run-time memory barriers in the >> atomic_inc() and atomic_dec() additions, which means that this is not >> safe, because memory operations on CPU 1 can be reordered. It's safe >> as shown *if* there are memory barriers to keep the order as shown: >> >> CPU 0 CPU 1 >> ------ -------------- >> atomic_inc(val) (no run-time memory barrier!) >> pmd_clear(pte) >> if (val) >> run_on_all_cpus(): IPI >> local_irq_disable() (also not a mem barrier) >> >> READ(pte) >> if(pte) >> walk page tables >> >> local_irq_enable() (still not a barrier) >> atomic_dec(val) >> >> free(pte) >> >> thanks, > > This is serialize: > > void serialize_against_pte_lookup(struct mm_struct *mm) > { > smp_mb(); > if (running_lockless_pgtbl_walk(mm)) > smp_call_function_many(mm_cpumask(mm), do_nothing, > NULL, 1); > } > > That would mean: > > CPU 0 CPU 1 > ------ -------------- > atomic_inc(val) > pmd_clear(pte) > smp_mb() > if (val) > run_on_all_cpus(): IPI > local_irq_disable() > > READ(pte) > if(pte) > walk page tables > > local_irq_enable() (still not a barrier) > atomic_dec(val) > > By https://www.kernel.org/doc/Documentation/memory-barriers.txt : > 'If you need all the CPUs to see a given store at the same time, use > smp_mb().' > > Is it not enough? Nope. CPU 1 memory accesses could be re-ordered, as I said above: CPU 0 CPU 1 ------ -------------- READ(pte) (re-ordered at run time) atomic_inc(val) (no run-time memory barrier!) pmd_clear(pte) if (val) run_on_all_cpus(): IPI local_irq_disable() (also not a mem barrier) if(pte) walk page tables ... > Do you suggest adding 'smp_mb()' after atomic_{inc,dec} ? > Yes (approximately: I'd have to look closer to see which barrier call is really required). Unless there is something else that is providing the barrier, which is why I called this a pre-existing question: it seems like the interrupt interlock in the current gup_fast() might not have what it needs. In other words, if your code needs a barrier, then the pre-existing gup_fast() code probably does, too. thanks, -- John Hubbard NVIDIA