Messages in this thread | | | Subject | Re: [PATCH 4/6] mm: hugetlb_vmemmap: add missing smp_wmb() before set_pte_at() | From | Miaohe Lin <> | Date | Thu, 18 Aug 2022 09:55:32 +0800 |
| |
On 2022/8/18 9:14, Yin, Fengwei wrote: > > > On 8/17/2022 7:21 PM, Muchun Song wrote: >> >> >>> On Aug 17, 2022, at 16:41, Miaohe Lin <linmiaohe@huawei.com> wrote: >>> >>> On 2022/8/17 10:53, Muchun Song wrote: >>>> >>>> >>>>> On Aug 16, 2022, at 21:05, Miaohe Lin <linmiaohe@huawei.com> wrote: >>>>> >>>>> 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. >>>> >>>> I’m not sure if you are right. I think it is set_pte_at()’s responsibility. >>> >>> Maybe not. There're many call sites do the similar things: >>> >>> hugetlb_mcopy_atomic_pte >>> __do_huge_pmd_anonymous_page >>> collapse_huge_page >>> do_anonymous_page >>> migrate_vma_insert_page >>> mcopy_atomic_pte >>> >>> Take do_anonymous_page as an example: >>> >>> /* >>> * 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.
Thanks, Miaohe Lin
| |