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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 494D0C00140 for ; Thu, 18 Aug 2022 10:54:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6FCFF6B0075; Thu, 18 Aug 2022 06:54:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6AC6B6B0078; Thu, 18 Aug 2022 06:54:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 574E88D0001; Thu, 18 Aug 2022 06:54:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 4A09F6B0075 for ; Thu, 18 Aug 2022 06:54:38 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 1C969806A0 for ; Thu, 18 Aug 2022 10:54:38 +0000 (UTC) X-FDA: 79812405036.07.590BF90 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf05.hostedemail.com (Postfix) with ESMTP id A5299100333 for ; Thu, 18 Aug 2022 10:48:44 +0000 (UTC) Received: from canpemm500002.china.huawei.com (unknown [172.30.72.57]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4M7cT50MGQzkWPd; Thu, 18 Aug 2022 15:48:41 +0800 (CST) Received: from [10.174.177.76] (10.174.177.76) by canpemm500002.china.huawei.com (7.192.104.244) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 18 Aug 2022 15:52:02 +0800 Subject: Re: [PATCH 4/6] mm: hugetlb_vmemmap: add missing smp_wmb() before set_pte_at() To: Muchun Song , "Yin, Fengwei" CC: Andrew Morton , Mike Kravetz , Muchun Song , Linux MM , References: <20220816130553.31406-1-linmiaohe@huawei.com> <20220816130553.31406-5-linmiaohe@huawei.com> <0EAF1279-6A1C-41FA-9A32-414C36B3792A@linux.dev> <019c1272-9d01-9d51-91a0-2d656b25c318@intel.com> <18adbf89-473e-7ba6-9a2b-522e1592bdc6@huawei.com> <9c791de0-b702-1bbe-38a4-30e87d9d1b95@intel.com> <931536E2-3948-40AB-88A7-E36F67954AAA@linux.dev> From: Miaohe Lin Message-ID: <7be98c64-88a1-3bee-7f92-67bb1f4f495b@huawei.com> Date: Thu, 18 Aug 2022 15:52:02 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <931536E2-3948-40AB-88A7-E36F67954AAA@linux.dev> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.177.76] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To canpemm500002.china.huawei.com (7.192.104.244) X-CFilter-Loop: Reflected ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660819725; a=rsa-sha256; cv=none; b=Hmdq6H8K/tyg4rume6hDTOSipI7TDo00tZAqWoF3/hUxKES6XWpyn8lqLtmtGhDooUBgzL Z8punAnRxKveal52l5J4IK/4EUWDxD662VwZBccPqNcM1uimKu6yiLbz0a4Mux5RVQKnwL 62Q9sqg0XjWWa3/2diDiznMrhgIcYUg= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf05.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660819725; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IXIf0dy6agjbJzbdoyjGVjbxGRw3xi3UOJp9X3+dDkA=; b=Ia5dIz/oWp0ltJxHdkdaC3QWgkd1zfPEihfriimcSwRkjnfYQtznG3R1WEsrst51ZjTlLa DGXbmmt7k2Q9eavwEyKntPJoKNjy9rgFpYa+p4dHfs7J/uAyVbIqoBjYRZE8yMjD1AUU6y n0SX+ETUbt7+BGUKgsMMq+GEb25ohfM= Authentication-Results: imf05.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf05.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: A5299100333 X-Rspam-User: X-Stat-Signature: k7dfjuxay7cxknwqoga1x4kzizs53nir X-HE-Tag: 1660819724-905817 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 2022/8/18 10:47, Muchun Song wrote: > > >> On Aug 18, 2022, at 10:00, Yin, Fengwei wrote: >> >> >> >> On 8/18/2022 9:55 AM, Miaohe Lin wrote: >>>>>> /* >>>>>> * The memory barrier inside __SetPageUptodate makes sure that >>>>>> * preceding stores to the page contents become visible before >>>>>> * the set_pte_at() write. >>>>>> */ >>>>>> __SetPageUptodate(page); >>>>> IIUC, the case here we should make sure others (CPUs) can see new page’s >>>>> contents after they have saw PG_uptodate is set. I think commit 0ed361dec369 >>>>> can tell us more details. >>>>> >>>>> I also looked at commit 52f37629fd3c to see why we need a barrier before >>>>> set_pte_at(), but I didn’t find any info to explain why. I guess we want >>>>> to make sure the order between the page’s contents and subsequent memory >>>>> accesses using the corresponding virtual address, do you agree with this? >>>> This is my understanding also. Thanks. >>> That's also my understanding. Thanks both. >> I have an unclear thing (not related with this patch directly): Who is response >> for the read barrier in the read side in this case? >> >> For SetPageUptodate, there are paring write/read memory barrier. >> > > I have the same question. So I think the example proposed by Miaohe is a little > difference from the case (hugetlb_vmemmap) here. Per my understanding, memory barrier in PageUptodate() is needed because user might access the page contents using page_address() (corresponding pagetable entry already exists) soon. But for the above proposed case, if user wants to access the page contents, the corresponding pagetable should be visible first or the page contents can't be accessed. So there should be a data dependency acting as memory barrier between pagetable entry is loaded and page contents is accessed. Or am I miss something? Thanks, Miaohe Lin