[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <97e3a8f2-df75-306e-2edf-85976c168955@nvidia.com>
Date: Tue, 6 Dec 2022 13:03:45 -0800
From: John Hubbard <jhubbard@...dia.com>
To: Peter Xu <peterx@...hat.com>
CC: Mike Kravetz <mike.kravetz@...cle.com>, <linux-mm@...ck.org>,
<linux-kernel@...r.kernel.org>,
James Houghton <jthoughton@...gle.com>,
"Jann Horn" <jannh@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
"Andrea Arcangeli" <aarcange@...hat.com>,
Rik van Riel <riel@...riel.com>,
Nadav Amit <nadav.amit@...il.com>,
Miaohe Lin <linmiaohe@...wei.com>,
Muchun Song <songmuchun@...edance.com>,
David Hildenbrand <david@...hat.com>
Subject: Re: [PATCH 08/10] mm/hugetlb: Make walk_hugetlb_range() safe to pmd
unshare
On 12/6/22 08:45, Peter Xu wrote:
> I've got a fixup attached. John, since this got your attention please also
> have a look too in case there's further issues.
>
Well, one question: Normally, the pattern of "release_lock(A); call f();
acquire_lock(A);" is tricky, because one must revalidate that the state
protected by A has not changed while the lock was released. However, in
this case, it's letting page fault handling proceed, which already
assumes that pages might be gone, so generally that seems OK.
However, I'm lagging behind on understanding what the vma lock actually
protects. It seems to be a hugetlb-specific protection for concurrent
freeing of the page tables? If so, then running a page fault handler
seems safe. If there's something else it protects, then we might need to
revalidate that after re-acquiring the vma lock.
Also, scattering hugetlb-specific locks throughout mm seems like an
unfortuate thing, I wonder if there is a longer term plan to Not Do
That?
thanks,
--
John Hubbard
NVIDIA
Powered by blists - more mailing lists