Re: [PATCH 1/2] hugetlb: Do not clear hugetlb dtor until allocating vmemmap

[Mike Kravetz]

On 07/12/23 11:14, Mike Kravetz wrote:
> On 07/12/23 16:03, Muchun Song wrote:
> > > On Jul 12, 2023, at 06:09, Mike Kravetz <mike.kravetz@xxxxxxxxxx> wrote:
> > > 
> > > Note that this will leave hugetlb pages in a state where they are marked
> > > free (by hugetlb specific page flag) and have a ref count.  This is not
> > > a normal state.  The only code that would notice is the memory error
> > > code, and it is set up to retry in such a case.
> > > 
> > > A subsequent patch will create a routine to do bulk processing of
> > > vmemmap allocation.  This will eliminate a lock/unlock cycle for each
> > > hugetlb page in the case where we are freeing a large number of pages.
> > > 
> > > Fixes: ad2fa3717b74 ("mm: hugetlb: alloc the vmemmap pages associated with each HugeTLB page")
> > > Cc: <stable@xxxxxxxxxxxxxxx>
> > > Signed-off-by: Mike Kravetz <mike.kravetz@xxxxxxxxxx>
> > 
> > Hi Mike,
> > 
> > I have seen an issue proposed by Jiaqi Yan in [1]. I didn't see any
> > resolution for it. Am I missing something with this fix?
> > 
> > [1] https://lore.kernel.org/linux-mm/CACw3F53iPiLrJt4pyaX2aaZ5BVg9tj8x_k6-v7=9Xn1nrh=UCw@xxxxxxxxxxxxxx/
> > 
> 
> My mistake!  I sent the old version of the patch.
> 
> The new version was modified to simply check the destructor via
> folio_test_hugetlb() in order to decide if it should be cleared.
> 
> I will send V2.  Sorry!

I was about to send v2 when I noticed that this approach opened another
race window.  :(  Closing the window should be just a matter of
reordering code.  I will take a day or two to make sure I did not miss
something else.
-- 
Mike Kravetz