From: Mike Rapoport <rppt@linux.ibm.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Nick Piggin <npiggin@gmail.com>, Hugh Dickins <hughd@google.com>,
Peter Zijlstra <peterz@infradead.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org, hch@lst.de,
rdunlap@infradead.org
Subject: Re: [PATCH v2] page_alloc: Fix freeing non-compound pages
Date: Tue, 29 Sep 2020 10:26:22 +0300 [thread overview]
Message-ID: <20200929072622.GN2645148@linux.ibm.com> (raw)
In-Reply-To: <20200929034026.GA20115@casper.infradead.org>
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.
next prev parent reply other threads:[~2020-09-29 7:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-26 21:39 [PATCH v2] page_alloc: Fix freeing non-compound pages Matthew Wilcox (Oracle)
2020-09-29 1:03 ` Andrew Morton
2020-09-29 1:17 ` Matthew Wilcox
2020-09-29 4:46 ` Andrew Morton
2020-09-29 22:53 ` Matthew Wilcox
2020-10-19 1:00 ` Nicholas Piggin
2020-09-29 3:40 ` Matthew Wilcox
2020-09-29 7:26 ` Mike Rapoport [this message]
2020-09-29 14:06 ` Matthew Wilcox
2020-09-30 9:17 ` Mike Rapoport
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200929072622.GN2645148@linux.ibm.com \
--to=rppt@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=hch@lst.de \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@gmail.com \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.