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