Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain;
        charset=utf-8
MIME-Version: 1.0
Subject: Re: [PATCH 4/6] mm: hugetlb_vmemmap: add missing smp_wmb() before
 set_pte_at()
From:   Muchun Song <muchun.song@linux.dev>
In-Reply-To: <bfb89f55-a618-4b36-7075-654922a8ddaa@huawei.com>
Date:   Mon, 22 Aug 2022 18:23:27 +0800
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Mike Kravetz <mike.kravetz@oracle.com>,
        Muchun Song <songmuchun@bytedance.com>,
        Linux MM <linux-mm@kvack.org>, linux-kernel@vger.kernel.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <F8381885-8B9F-405B-A860-AFB8A675D5A7@linux.dev>
References: <20220816130553.31406-1-linmiaohe@huawei.com>
 <20220816130553.31406-5-linmiaohe@huawei.com>
 <CBD5F92C-1D62-4331-A214-5B6D08E35809@linux.dev>
 <bfb89f55-a618-4b36-7075-654922a8ddaa@huawei.com>
To:     Miaohe Lin <linmiaohe@huawei.com>
Precedence: bulk


> On Aug 22, 2022, at 16:45, Miaohe Lin <linmiaohe@huawei.com> wrote:
>=20
> On 2022/8/20 16:12, Muchun Song wrote:
>>=20
>>=20
>>> On Aug 16, 2022, at 21:05, Miaohe Lin <linmiaohe@huawei.com> 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 found another place where is a similar case. See =
kasan_populate_vmalloc_pte() in
>> mm/kasan/shadow.c.=20
>=20
> Thanks for your report.
>=20
>>=20
>> Should we fix it as well?
>=20
> I'm not familiar with kasan yet, but I think memory barrier is needed =
here or memory corrupt
> can't be detected until the contents are visible. smp_mb__after_atomic =
before set_pte_at should
> be enough? What's your opinion?

I didn=E2=80=99t see any atomic operation between set_pte_at() and =
memset(), I don=E2=80=99t think
smp_mb__after_atomic() is feasible if we really need to insert a =
barrier. I suggest
you to send a RFC patch to KASAN maintainers, they are more familiar =
with this than
us.

Thanks.

>=20
> Thanks,
> Miaohe Lin
>=20
>=20