linux-kernel - Re: [RFC PATCH 7/8] hugetlb: add update_and_free_page_no

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <YFis0mIbkTWaX7tM@dhcp22.suse.cz>
Date:   Mon, 22 Mar 2021 15:42:26 +0100
From:   Michal Hocko <mhocko@...e.com>
To:     Mike Kravetz <mike.kravetz@...cle.com>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Shakeel Butt <shakeelb@...gle.com>,
        Oscar Salvador <osalvador@...e.de>,
        David Hildenbrand <david@...hat.com>,
        Muchun Song <songmuchun@...edance.com>,
        David Rientjes <rientjes@...gle.com>,
        Miaohe Lin <linmiaohe@...wei.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Matthew Wilcox <willy@...radead.org>,
        HORIGUCHI NAOYA <naoya.horiguchi@....com>,
        "Aneesh Kumar K . V" <aneesh.kumar@...ux.ibm.com>,
        Waiman Long <longman@...hat.com>, Peter Xu <peterx@...hat.com>,
        Mina Almasry <almasrymina@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC PATCH 7/8] hugetlb: add update_and_free_page_no_sleep for
 irq context

On Fri 19-03-21 15:42:08, Mike Kravetz wrote:
> The locks acquired in free_huge_page are irq safe.  However, in certain
> circumstances the routine update_and_free_page could sleep.  Since
> free_huge_page can be called from any context, it can not sleep.
> 
> Use a waitqueue to defer freeing of pages if the operation may sleep.  A
> new routine update_and_free_page_no_sleep provides this functionality
> and is only called from free_huge_page.
> 
> Note that any 'pages' sent to the workqueue for deferred freeing have
> already been removed from the hugetlb subsystem.  What is actually
> deferred is returning those base pages to the low level allocator.

This patch or its alternative would need to be applied prior to patch 6
which makes the whole context IRQ safe.

Besides that the changelog doesn't really say anything about changed
user visible behavior change. Now if somebody decreases the GB huge pool
from the userspace the real effect on the freed up memory will be
postponed to some later time. That "later" is unpredictable as it
depends on WQ utilization. We definitely need some sort of
wait_for_inflight pages. One way to do that would be to have a dedicated
WQ and schedule a sync work item after the pool has been shrunk and wait
for that item.

-- 
Michal Hocko
SUSE Labs