From: Matthew Wilcox <willy@infradead.org>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Hugh Dickins <hughd@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@suse.com>,
Zhou Guanghui <zhouguanghui1@huawei.com>, Zi Yan <ziy@nvidia.com>,
Shakeel Butt <shakeelb@google.com>, Roman Gushchin <guro@fb.com>,
linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH] mm: page_alloc: fix memcg accounting leak in speculative cache lookup
Date: Tue, 23 Mar 2021 19:12:07 +0000 [thread overview]
Message-ID: <20210323191207.GJ1719932@casper.infradead.org> (raw)
In-Reply-To: <YFo7SOni0s0TbXUm@cmpxchg.org>
On Tue, Mar 23, 2021 at 03:02:32PM -0400, Johannes Weiner wrote:
> >From f6f062a3ec46f4fb083dcf6792fde9723f18cfc5 Mon Sep 17 00:00:00 2001
> From: Johannes Weiner <hannes@cmpxchg.org>
> Date: Fri, 19 Mar 2021 02:17:00 -0400
> Subject: [PATCH] mm: page_alloc: fix allocation imbalances from speculative
> cache lookup
>
> When the freeing of a higher-order page block (non-compound) races
> with a speculative page cache lookup, __free_pages() needs to leave
> the first order-0 page in the chunk to the lookup but free the buddy
> pages that the lookup doesn't know about separately.
>
> There are currently two problems with it:
>
> 1. It checks PageHead() to see whether we're dealing with a compound
> page after put_page_testzero(). But the speculative lookup could
> have freed the page after our put and cleared PageHead, in which
> case we would double free the tail pages.
>
> To fix this, test PageHead before the put and cache the result for
> afterwards.
>
> 2. If such a higher-order page is charged to a memcg (e.g. !vmap
> kernel stack)), only the first page of the block has page->memcg
> set. That means we'll uncharge only one order-0 page from the
> entire block, and leak the remainder.
>
> To fix this, add a split_page_memcg() before it starts freeing tail
> pages, to ensure they all have page->memcg set up.
>
> While at it, also update the comments a bit to clarify what exactly is
> happening to the page during that race.
>
> Fixes: e320d3012d25 mm/page_alloc.c: fix freeing non-compound pages
> Reported-by: Hugh Dickins <hughd@google.com>
> Reported-by: Matthew Wilcox <willy@infradead.org>
> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
> Cc: <stable@vger.kernel.org> # 5.10+
This version makes me happy.
Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Thanks for fixing my buggy fix.
next prev parent reply other threads:[~2021-03-23 19:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-19 7:15 [PATCH] mm: page_alloc: fix memcg accounting leak in speculative cache lookup Johannes Weiner
2021-03-19 13:21 ` Matthew Wilcox
2021-03-20 1:52 ` Hugh Dickins
2021-03-20 3:25 ` Matthew Wilcox
2021-03-23 19:02 ` Johannes Weiner
2021-03-23 19:12 ` Matthew Wilcox [this message]
2021-03-23 20:10 ` Hugh Dickins
2021-03-26 1:55 ` Hugh Dickins
2021-03-26 2:51 ` Matthew Wilcox
2021-03-26 4:04 ` Hugh Dickins
2021-03-26 12:07 ` Matthew Wilcox
2021-03-24 8:58 ` Michal Hocko
2021-03-22 9:55 ` Michal Hocko
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=20210323191207.GJ1719932@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=shakeelb@google.com \
--cc=zhouguanghui1@huawei.com \
--cc=ziy@nvidia.com \
/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;
as well as URLs for NNTP newsgroup(s).