On Tue, Sep 29, 2020 at 03:06:22PM +0100, Matthew Wilcox wrote: > 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: I like this one Acked-by: Mike Rapoport <rppt@xxxxxxxxxxxxx> > /** > * __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. > */ > -- Sincerely yours, Mike.
