lkml.org 
[lkml]   [2020]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2] page_alloc: Fix freeing non-compound pages
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@linux.ibm.com>

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

\
 
 \ /
  Last update: 2020-09-30 11:18    [W:0.041 / U:5.804 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site