Re: [PATCH v2] page_alloc: Fix freeing non-compound pages

[Matthew Wilcox]

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.
 */