From: Alexander Duyck <alexander.duyck@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Qian Cai <cai@lca.pw>, Heiko Carstens <heiko.carstens@de.ibm.com>,
gor@linux.ibm.com, David Hildenbrand <david@redhat.com>,
borntraeger@de.ibm.com, linux-s390@vger.kernel.org,
linux-mm <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm/page_alloc: fix a crash in free_pages_prepare()
Date: Fri, 27 Sep 2019 15:17:25 -0700 [thread overview]
Message-ID: <CAKgT0UfZBNmn1aZdvRT6Yvki3LBi_Nr5hjkYeSnpA7S8kY58-Q@mail.gmail.com> (raw)
In-Reply-To: <20190927145945.846a3f3405d3af066827d3f5@linux-foundation.org>
On Fri, Sep 27, 2019 at 2:59 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Fri, 27 Sep 2019 17:28:06 -0400 Qian Cai <cai@lca.pw> wrote:
>
> > >
> > > So I think you've moved the arch_free_page() to be after the final
> > > thing which can access page contents, yes? If so, we should have a
> > > comment in free_pages_prepare() to attmept to prevent this problem from
> > > reoccurring as the code evolves?
> >
> > Right, something like this above arch_free_page() there?
> >
> > /*
> > * It needs to be just above kernel_map_pages(), as s390 could mark those
> > * pages unused and then trigger a fault when accessing.
> > */
>
> I did this.
>
> --- a/mm/page_alloc.c~mm-page_alloc-fix-a-crash-in-free_pages_prepare-fix
> +++ a/mm/page_alloc.c
> @@ -1179,7 +1179,13 @@ static __always_inline bool free_pages_p
> kernel_init_free_pages(page, 1 << order);
>
> kernel_poison_pages(page, 1 << order, 0);
> + /*
> + * arch_free_page() can make the page's contents inaccessible. s390
> + * does this. So nothing which can access the page's contents should
> + * happen after this.
> + */
> arch_free_page(page, order);
> +
> if (debug_pagealloc_enabled())
> kernel_map_pages(page, 1 << order, 0);
>
So the question I would have is what is the state of the page after it
has been marked unused and then pulled back in? I'm assuming it will
be all 0s.
I know with the work I am still doing on marking pages as unused this
ends up being an additional item that we will need to pay attention
to, however in our case we will just be initializing the page as zero
if we end up evicting it from the guest.
next prev parent reply other threads:[~2019-09-27 22:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-27 19:47 Qian Cai
2019-09-27 20:48 ` Andrew Morton
2019-09-27 21:15 ` Qian Cai
2019-09-30 7:44 ` Heiko Carstens
2019-09-27 21:02 ` Andrew Morton
2019-09-27 21:28 ` Qian Cai
2019-09-27 21:59 ` Andrew Morton
2019-09-27 22:17 ` Alexander Duyck [this message]
2019-09-28 9:06 ` David Hildenbrand
2019-09-30 6:27 ` Christian Borntraeger
2019-09-30 6:30 ` Christian Borntraeger
2019-09-30 11:00 ` Michal Hocko
2019-09-30 11:04 ` Kirill A. Shutemov
2019-09-30 11:22 ` Qian Cai
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=CAKgT0UfZBNmn1aZdvRT6Yvki3LBi_Nr5hjkYeSnpA7S8kY58-Q@mail.gmail.com \
--to=alexander.duyck@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=borntraeger@de.ibm.com \
--cc=cai@lca.pw \
--cc=david@redhat.com \
--cc=gor@linux.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.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