From: Matthew Wilcox <willy@infradead.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Nick Piggin <npiggin@gmail.com>, Hugh Dickins <hughd@google.com>,
Peter Zijlstra <peterz@infradead.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] page_alloc: Fix freeing non-compound pages
Date: Tue, 29 Sep 2020 02:17:19 +0100 [thread overview]
Message-ID: <20200929011719.GD30994@casper.infradead.org> (raw)
In-Reply-To: <20200928180307.7573f3b6128b5e3007dfc9f0@linux-foundation.org>
On Mon, Sep 28, 2020 at 06:03:07PM -0700, Andrew Morton wrote:
> On Sat, 26 Sep 2020 22:39:19 +0100 "Matthew Wilcox (Oracle)" <willy@infradead.org> wrote:
>
> > Here is a very rare race which leaks memory:
>
> Not worth a cc:stable?
Yes, it probably should have been. I just assume the stablebot will
pick up anything that has a Fixes: tag.
> > Page P0 is allocated to the page cache. Page P1 is free.
> >
> > Thread A Thread B Thread C
> > find_get_entry():
> > xas_load() returns P0
> > Removes P0 from page cache
> > P0 finds its buddy P1
> > alloc_pages(GFP_KERNEL, 1) returns P0
> > P0 has refcount 1
> > page_cache_get_speculative(P0)
> > P0 has refcount 2
> > __free_pages(P0)
>
> __free_pages(P0, 1), I assume.
Good catch. That was what I meant to type.
> > P0 has refcount 1
> > put_page(P0)
>
> but this is implicitly order 0
Right, because it's not a compound page.
> > P1 is not freed
>
> huh.
Yeah. Nasty, and we'll never know how often it was hit.
> > Fix this by freeing all the pages in __free_pages() that won't be freed
> > by the call to put_page(). It's usually not a good idea to split a page,
> > but this is a very unlikely scenario.
> >
> > ...
> >
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -4947,6 +4947,9 @@ void __free_pages(struct page *page, unsigned int order)
> > {
> > if (put_page_testzero(page))
> > free_the_page(page, order);
> > + else if (!PageHead(page))
> > + while (order-- > 0)
> > + free_the_page(page + (1 << order), order);
>
> 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?
Well, poot. I lost that comment in the shuffling of patches. In a
different tree, I have:
@@ -4943,10 +4943,19 @@ static inline void free_the_page(struct page *page, unsi
gned int order)
__free_pages_ok(page, order);
}
+/*
+ * If we free a non-compound allocation, another thread may have a
+ * speculative reference to the first page. It has no way of knowing
+ * about the rest of the allocation, so we have to free all but the
+ * first page here.
+ */
void __free_pages(struct page *page, unsigned int order)
{
if (put_page_testzero(page))
free_the_page(page, order);
+ else if (!PageHead(page))
+ while (order-- > 0)
+ free_the_page(page + (1 << order), order);
}
EXPORT_SYMBOL(__free_pages);
Although I'm now thinking of making that comment into kernel-doc and
turning it into advice to the caller rather than an internal note to
other mm developers.
next prev parent reply other threads:[~2020-09-29 1:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-26 21:39 Matthew Wilcox (Oracle)
2020-09-29 1:03 ` Andrew Morton
2020-09-29 1:17 ` Matthew Wilcox [this message]
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
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=20200929011719.GD30994@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@gmail.com \
--cc=peterz@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox