All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Longpeng (Mike)" <longpeng2@huawei.com>
To: Matthew Wilcox <willy@infradead.org>, Qian Cai <cai@lca.pw>
Cc: <akpm@linux-foundation.org>, <mike.kravetz@oracle.com>,
	<kirill.shutemov@linux.intel.com>, <linux-kernel@vger.kernel.org>,
	<arei.gonglei@huawei.com>, <weidong.huang@huawei.com>,
	<weifuqiang@huawei.com>, <kvm@vger.kernel.org>,
	<linux-mm@kvack.org>,
	"Sean Christopherson" <sean.j.christopherson@intel.com>,
	<stable@vger.kernel.org>
Subject: Re: [PATCH v2] mm/hugetlb: fix a addressing exception caused by huge_pte_offset()
Date: Sun, 23 Feb 2020 09:24:01 +0800	[thread overview]
Message-ID: <dfbfbf46-483a-808f-d197-388f75569d9c@huawei.com> (raw)
In-Reply-To: <20200222170222.GJ24185@bombadil.infradead.org>

在 2020/2/23 1:02, Matthew Wilcox 写道:
> On Sat, Feb 22, 2020 at 02:33:10PM +0800, Longpeng (Mike) wrote:
>> 在 2020/2/22 13:23, Qian Cai 写道:
>>>> On Feb 21, 2020, at 10:34 PM, Longpeng(Mike) <longpeng2@huawei.com> wrote:
>>>>
>>>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>>>> index dd8737a..90daf37 100644
>>>> --- a/mm/hugetlb.c
>>>> +++ b/mm/hugetlb.c
>>>> @@ -4910,28 +4910,30 @@ pte_t *huge_pte_offset(struct mm_struct *mm,
>>>> {
>>>>    pgd_t *pgd;
>>>>    p4d_t *p4d;
>>>> -    pud_t *pud;
>>>> -    pmd_t *pmd;
>>>> +    pud_t *pud, pud_entry;
>>>> +    pmd_t *pmd, pmd_entry;
>>>>
>>>>    pgd = pgd_offset(mm, addr);
>>>> -    if (!pgd_present(*pgd))
>>>> +    if (!pgd_present(READ_ONCE(*pgd)))
>>>>        return NULL;
>>>>    p4d = p4d_offset(pgd, addr);
>>>> -    if (!p4d_present(*p4d))
>>>> +    if (!p4d_present(READ_ONCE(*p4d)))
>>>>        return NULL;
>>>
>>> What’s the point of READ_ONCE() on those two places?
>>>
>> As explained in the commit messages, it's for safe(e.g. avoid the compilier
>> mischief). You can also find the same usage in the ARM64's huge_pte_offset() in
>> arch/arm64/mm/hugetlbpage.c
> 
> I rather agree with Qian; if we need something like READ_ONCE() here,
> why don't we always need it as part of pgd_present()?  It seems like an
> unnecessary burden for every user.
> 
Hi Matthew & Qian,

Firstly, this is NOT a 'blindly copy', it's an unwise words. I don't know
whether you read the commit message (commit 20a004e7) of ARM64's huge_pte_offset
? If you read, I think worry about the safe is necessary.

Secondly, huge_pte_offset in mm/hugetlb.c is for ARCH_WANT_GENERAL_HUGETLB, many
architectures use it, can you make sure there is no issue on all the
architectures using it with all the version of gcc ?

Thirdly, there are several places use READ_ONCE to access the page table in mm/*
(e.g. gup_pmd_range), they're also generical for all architectures, and they're
much more like unnecessary than here, so why there can use but not here? What's
more, you can read this commit 688272809.

-- 
Regards,
Longpeng(Mike)


  reply	other threads:[~2020-02-23  1:24 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-22  5:23 [PATCH v2] mm/hugetlb: fix a addressing exception caused by huge_pte_offset() Qian Cai
2020-02-22  6:33 ` Longpeng (Mike)
2020-02-22 11:50   ` Qian Cai
2020-02-22 17:02   ` Matthew Wilcox
2020-02-23  1:24     ` Longpeng (Mike) [this message]
2020-02-27 21:41       ` Mike Kravetz
2020-03-21 22:46         ` Andrew Morton
  -- strict thread matches above, loose matches on Subject: below --
2020-02-22  3:33 Longpeng(Mike)
2020-03-21 23:38 ` Mike Kravetz
2020-03-23  2:03   ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2020-03-23  2:03     ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2020-03-23  2:54     ` Mike Kravetz
2020-03-23  2:54       ` Mike Kravetz
2020-03-23  3:43       ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2020-03-23  3:43         ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2020-03-23 14:40       ` Sean Christopherson
2020-03-23 14:40         ` Sean Christopherson
2020-03-23 16:44         ` Jason Gunthorpe
2020-03-23 16:44           ` Jason Gunthorpe
2020-03-23 16:09   ` Jason Gunthorpe
2020-03-23 17:27     ` Mike Kravetz
2020-03-23 18:07       ` Jason Gunthorpe
2020-03-23 20:35         ` Mike Kravetz
2020-03-23 22:52           ` Jason Gunthorpe
2020-03-24  2:37             ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2020-03-24  2:37               ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2020-03-24 11:55               ` Jason Gunthorpe
2020-03-24 11:55                 ` Jason Gunthorpe
2020-03-24 15:25                 ` Mike Kravetz
2020-03-24 15:25                   ` Mike Kravetz
2020-03-24 15:55                   ` Jason Gunthorpe
2020-03-24 15:55                     ` Jason Gunthorpe
2020-03-24 16:19                     ` Mike Kravetz
2020-03-24 16:19                       ` Mike Kravetz
2020-03-24 17:59                       ` Jason Gunthorpe
2020-03-24 17:59                         ` Jason Gunthorpe
2020-03-24 19:47                         ` Mike Kravetz
2020-03-24 19:47                           ` Mike Kravetz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dfbfbf46-483a-808f-d197-388f75569d9c@huawei.com \
    --to=longpeng2@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=arei.gonglei@huawei.com \
    --cc=cai@lca.pw \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=stable@vger.kernel.org \
    --cc=weidong.huang@huawei.com \
    --cc=weifuqiang@huawei.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.