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 D45D9C25B08 for ; Wed, 17 Aug 2022 11:21:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E3BA58D0002; Wed, 17 Aug 2022 07:21:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE9EE8D0001; Wed, 17 Aug 2022 07:21:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CB1E58D0002; Wed, 17 Aug 2022 07:21:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id BCF938D0001 for ; Wed, 17 Aug 2022 07:21:56 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 856E4A1500 for ; Wed, 17 Aug 2022 11:21:56 +0000 (UTC) X-FDA: 79808845032.26.54D16F3 Received: from out2.migadu.com (out2.migadu.com [188.165.223.204]) by imf29.hostedemail.com (Postfix) with ESMTP id D12631201E0 for ; Wed, 17 Aug 2022 11:21:55 +0000 (UTC) Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1660735313; h=from:from: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=PVxPk6+5X6DJJkwSaX0y9hA+rp5q+PorKKLpJBEA7eE=; b=h4rNBVsjUyBLhnBfmD1f1Hb5mRNfq3kgg4G1/r7wUE9ajpVQQMDbwO4I/ThtCZyfxsVc36 Xh3JyJo8zuS0qNfjknCuUR8o6ZF8VAv6kjCaifiYPlj1+fVCJWKUNL1gfMiHhMsT52+N14 2J2JPB5yB77Ym29HAQ7D/YcosOTXtfs= MIME-Version: 1.0 Subject: Re: [PATCH 4/6] mm: hugetlb_vmemmap: add missing smp_wmb() before set_pte_at() X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: Date: Wed, 17 Aug 2022 19:21:20 +0800 Cc: Andrew Morton , Mike Kravetz , Muchun Song , Linux MM , linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <0EAF1279-6A1C-41FA-9A32-414C36B3792A@linux.dev> References: <20220816130553.31406-1-linmiaohe@huawei.com> <20220816130553.31406-5-linmiaohe@huawei.com> To: Miaohe Lin X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: linux.dev ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=h4rNBVsj; spf=pass (imf29.hostedemail.com: domain of muchun.song@linux.dev designates 188.165.223.204 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660735316; a=rsa-sha256; cv=none; b=D6aObh3gmjx8SgUH0x1/CM/bSYokPJZq+iN90xaNGfITtUuLhc6n5AXK0fOxojG/28iRbt cazHxoadEsXS70c6xyXI8gtjg5cvjKaRZVClmdXVxReDCHctXOQIb9Il/MTnkFYFGOKDfY m7rGZjDYldc01YFmxdCCa0CEm2tKI1M= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660735316; 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:dkim-signature; bh=PVxPk6+5X6DJJkwSaX0y9hA+rp5q+PorKKLpJBEA7eE=; b=Yszg99ELy2Svjk6lg+OQKu7dhtcFSBkCr+ZPKGvXRYJJVCH7qECJeBcp7572AdP5bQihKr ESlEEdCWxxj6Kx/2VBmgzYbYHasWrDWiH/q8ZV3dx372o27f93Pgqez5QlXhnrfv70WXuM jfGdDJW0VrIx+W/9PPfG2yySNckS5U0= X-Stat-Signature: bqcru9or4o1hmzcrm1jtwnbey4mnxf71 X-Rspamd-Queue-Id: D12631201E0 X-Rspamd-Server: rspam08 Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=h4rNBVsj; spf=pass (imf29.hostedemail.com: domain of muchun.song@linux.dev designates 188.165.223.204 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev X-Rspam-User: X-HE-Tag: 1660735315-321557 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 Aug 17, 2022, at 16:41, Miaohe Lin wrote: >=20 > On 2022/8/17 10:53, Muchun Song wrote: >>=20 >>=20 >>> On Aug 16, 2022, at 21:05, Miaohe Lin wrote: >>>=20 >>> The memory barrier smp_wmb() is needed to make sure that preceding = stores >>> to the page contents become visible before the below set_pte_at() = write. >>=20 >> I=E2=80=99m not sure if you are right. I think it is set_pte_at()=E2=80= =99s responsibility. >=20 > Maybe not. There're many call sites do the similar things: >=20 > hugetlb_mcopy_atomic_pte > __do_huge_pmd_anonymous_page > collapse_huge_page > do_anonymous_page > migrate_vma_insert_page > mcopy_atomic_pte >=20 > Take do_anonymous_page as an example: >=20 > /* > * 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=E2=80=99s 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=E2=80=99t find any info to explain why. I guess = we want to make sure the order between the page=E2=80=99s contents and = subsequent memory accesses using the corresponding virtual address, do you agree with = this? Thanks. >=20 > So I think a memory barrier is needed before the set_pte_at() write. = Or am I miss something? >=20 > Thanks, > Miaohe Lin >=20 >> Take arm64 (since it is a Relaxed Memory Order model) as an example = (the >> following code snippet is set_pte()), I see a barrier guarantee. So I = am >> curious what issues you are facing. So I want to know the basis for = you to >> do this change. >>=20 >> static inline void set_pte(pte_t *ptep, pte_t pte) >> { >> *ptep =3D pte; >>=20 >> /* >> * Only if the new pte is valid and kernel, otherwise TLB = maintenance >> * or update_mmu_cache() have the necessary barriers. >> */ >> if (pte_valid_not_user(pte)) { >> dsb(ishst); >> isb(); >> } >> } >>=20 >> Thanks. >>=20