lkml.org 
[lkml]   [2020]   [Sep]   [29]   [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 04:40:26AM +0100, Matthew Wilcox wrote:
> On Mon, Sep 28, 2020 at 06:03:07PM -0700, Andrew Morton wrote:
> > Well that's weird and scary looking. `page' has non-zero refcount yet
> > we go and free random followon pages. Methinks it merits an
> > explanatory comment?
>
> Here's some kernel-doc. Opinions?
>
> /**
> * __free_pages - Free pages allocated with alloc_pages().
> * @page: The page pointer returned from alloc_pages().
> * @order: The order of the allocation.
> *
> * This function differs from put_page() in that it can free multi-page

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

> * allocations that were not allocated with %__GFP_COMP. This function
> * does not check that the @order passed in matches that of the
> * allocation, so it is possible to leak memory. Freeing more memory than
> * was allocated will probably be warned about by other debugging checks.
> *
> * It is only safe to use the page reference count to determine when
> * to free an allocation if you use %__GFP_COMP (in which case, you may
> * as well use put_page() to free the page). Another thread may have a
> * speculative reference to the first page, but it has no way of knowing
> * about the rest of the allocation, so we have to free all but the
> * first page here.
> *
> * Context: May be called in interrupt context but not NMI context.
> */
>

--
Sincerely yours,
Mike.

\
 
 \ /
  Last update: 2020-09-29 09:26    [W:0.148 / U:1.564 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site