[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200929140622.GE20115@casper.infradead.org>
Date: Tue, 29 Sep 2020 15:06:22 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Mike Rapoport <rppt@...ux.ibm.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Nick Piggin <npiggin@...il.com>,
Hugh Dickins <hughd@...gle.com>,
Peter Zijlstra <peterz@...radead.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, hch@....de, rdunlap@...radead.org
Subject: Re: [PATCH v2] page_alloc: Fix freeing non-compound pages
On Tue, Sep 29, 2020 at 10:26:22AM +0300, Mike Rapoport wrote:
> This sentence presumes existing description/prior knowledge about
> put_page().
>
> Maybe
>
> This function can free multi-page allocations that were not allocated
> with %__GFP_COMP, unlike put_page() that would free only the first page
> in such case. __free_pages() does not ...
Thanks. After waking up this morning I did a more extensive rewrite:
/**
* __free_pages - Free pages allocated with alloc_pages().
* @page: The page pointer returned from alloc_pages().
* @order: The order of the allocation.
*
* This function can free multi-page allocations that are not compound
* pages. It does not check that the @order passed in matches that of
* the allocation, so it is easy to leak memory. Freeing more memory
* than was allocated will probably emit a warning.
*
* If the last reference to this page is speculative, it will be released
* by put_page() which only frees the first page of a non-compound
* allocation. To prevent the remaining pages from being leaked, we free
* the subsequent pages here. If you want to use the page's reference
* count to decide when to free the allocation, you should allocate a
* compound page, and use put_page() instead of __free_pages().
*
* Context: May be called in interrupt context or holding a normal
* spinlock, but not in NMI context or while holding a raw spinlock.
*/
Powered by blists - more mailing lists