lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 5 Jan 2021 16:07:48 -0800
From:   Mike Kravetz <>
To:     Muchun Song <>
Cc:     Andrew Morton <>,
        Naoya Horiguchi <>,
        Andi Kleen <>,,
        Linux Memory Management List <>,
        LKML <>
Subject: Re: [External] Re: [PATCH 4/6] mm: hugetlb: add return -EAGAIN for

On 1/4/21 7:46 PM, Muchun Song wrote:
> On Tue, Jan 5, 2021 at 11:14 AM Muchun Song <> wrote:
>> On Tue, Jan 5, 2021 at 9:33 AM Mike Kravetz <> wrote:
>>> On 1/3/21 10:58 PM, Muchun Song wrote:
>>>> When dissolve_free_huge_page() races with __free_huge_page(), we can
>>>> do a retry. Because the race window is small.
>>> In general, I agree that the race window is small.  However, worst case
>>> would be if the freeing of the page is put on a work queue.  Is it acceptable
>>> to keep retrying in that case?  In addition, the 'Free some vmemmap' series
>>> may slow the free_huge_page path even more.
>> I also consider the 'Free some vmemmap' series case. In my next
>> version series, I will flush the work before dissolve_free_huge_page
>> returns when encountering this race. So the retry is acceptable.
>> Right?
> Hi Mike,
> How about flushing the @free_hpage_work when
> encountering this race?

Flushing should be fine.

The more I think about it, the more I think spinning to retry is not
going to be an issue.  Why?  As you mentioned the race window is quite
small.  It just makes me a bit nervous to retry in a tight loop.
Mike Kravetz

Powered by blists - more mailing lists