From: Mike Kravetz <mike.kravetz@oracle.com>
To: Peter Xu <peterx@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Andrew Morton <akpm@linux-foundation.org>,
Muchun Song <songmuchun@bytedance.com>,
Naoya Horiguchi <naoya.horiguchi@nec.com>
Subject: Re: [PATCH] mm/hugetlb: Fix pgtable lock on pmd sharing
Date: Mon, 12 Jun 2023 14:44:32 -0700 [thread overview]
Message-ID: <20230612214432.GE3704@monkey> (raw)
In-Reply-To: <ZIePspc+wgNeR0/H@x1n>
On 06/12/23 17:35, Peter Xu wrote:
> Hi, Mike!
>
> On Mon, Jun 12, 2023 at 01:44:18PM -0700, Mike Kravetz wrote:
> > Agree with this change. But, it does make one wonder if the pud_clear()
> > in huge_pmd_unshare is safe. Like here, we really should be holding the
> > higher level lock but are holding the PMD lock.
>
> The vma write lock? My memory tells me that you worked on the vma lock and
> one major reason was for that, but maybe I missed something?
>
> I did check again and all call sites should have that lock held, which
> looks fine here. One thing worth mention is pmd unshare should also always
> be gup-fast-safe because it never really releases the pgtable, unlike thp
> collapse.
Yes, Duh!
In the unshare case we KNOW what is mapped (the vma) via the PUD. So,
we certainly am synchronized with that access. I was just trying to
imagine some other situation where we may be walking the page table
without the vma lock held. However, you already took care of those call
sites.
Thanks!
You or Andrew can add,
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
--
Mike Kravetz
prev parent reply other threads:[~2023-06-12 21:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-12 16:04 [PATCH] mm/hugetlb: Fix pgtable lock on pmd sharing Peter Xu
2023-06-12 20:44 ` Mike Kravetz
2023-06-12 21:35 ` Peter Xu
2023-06-12 21:44 ` Mike Kravetz [this message]
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=20230612214432.GE3704@monkey \
--to=mike.kravetz@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=naoya.horiguchi@nec.com \
--cc=peterx@redhat.com \
--cc=songmuchun@bytedance.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).