[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200929034026.GA20115@casper.infradead.org>
Date: Tue, 29 Sep 2020 04:40:26 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Nick Piggin <npiggin@...il.com>, Hugh Dickins <hughd@...gle.com>,
Peter Zijlstra <peterz@...radead.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, hch@....de, rppt@...ux.ibm.com,
rdunlap@...radead.org
Subject: Re: [PATCH v2] page_alloc: Fix freeing non-compound pages
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
* 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.
*/
Powered by blists - more mailing lists