lkml.org 
[lkml]   [2021]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [External] Re: [PATCH v3 3/6] mm: hugetlb: fix a race between freeing and dissolving the page
    On Tue 12-01-21 18:13:02, Muchun Song wrote:
    > On Tue, Jan 12, 2021 at 6:02 PM Michal Hocko <mhocko@suse.com> wrote:
    > >
    > > On Sun 10-01-21 20:40:14, Muchun Song wrote:
    > > [...]
    > > > @@ -1770,6 +1788,14 @@ int dissolve_free_huge_page(struct page *page)
    > > > int nid = page_to_nid(head);
    > > > if (h->free_huge_pages - h->resv_huge_pages == 0)
    > > > goto out;
    > > > +
    > > > + /*
    > > > + * We should make sure that the page is already on the free list
    > > > + * when it is dissolved.
    > > > + */
    > > > + if (unlikely(!PageHugeFreed(head)))
    > > > + goto out;
    > > > +
    > >
    > > Do you really want to report EBUSY in this case? This doesn't make much
    > > sense to me TBH. I believe you want to return 0 same as when you race
    > > and the page is no longer PageHuge.
    >
    > Return 0 is wrong. Because the page is not freed to the buddy allocator.
    > IIUC, dissolve_free_huge_page returns 0 when the page is already freed
    > to the buddy allocator. Right?

    0 is return when the page is either dissolved or it doesn't need
    dissolving. If there is a race with somebody else freeing the page then
    there is nothing to dissolve. Under which condition it makes sense to
    report the failure and/or retry dissolving?
    --
    Michal Hocko
    SUSE Labs

    \
     
     \ /
      Last update: 2021-01-12 12:20    [W:3.308 / U:0.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site