From: Andrea Arcangeli <aarcange@redhat.com>
To: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>
Cc: Andi Kleen <ak@linux.intel.com>,
Rafael Aquini <aquini@redhat.com>,
Waiman Long <longman@redhat.com>,
linux-kernel@vger.kernel.org
Subject: [PATCH 0/1] x86: restore the write back cache of reserved RAM in iounmap()
Date: Thu, 19 Nov 2020 12:59:01 -0500 [thread overview]
Message-ID: <20201119175902.17394-1-aarcange@redhat.com> (raw)
Hello everyone,
We identified some PCD set on the direct mapping causing hardly
reproducible performance issues and this patch fixes the ultimate root
cause.
The caller for now has been tweaked to avoid triggering this case (now
that we know about it) however if the observations on the proposed fix
aren't correct, it'd be great if we could still do some other change
to ioremap/iounmap and perhaps the other memtype APIs, to be sure
those PCD/PWT leftovers won't happen again a few years from now in
another place.
For example one more complex alternative would be to use the
page_mapcount of reserved pages (currently unused) to do proper
refcounting on the overlapping ioremap so you can resync the kernel
direct mapping to write back only at the very last iounmap.
Or a much simpler alternative that would remain fully neutral for
overlapping ioremaps, would be to overwrite all page_count of reserved
RAM in a way that if they're ever freed later it'll trigger a crash
during __free_pages.
==
// SPDX-License-Identifier: GPL-2.0-only
/*
* ioremap.c
*
* Copyright (C) 2020 Red Hat, Inc.
*
* Reproducer for bug io iounmap.
*/
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/mm.h>
#include <asm/io.h>
#define NR_PAGES 512
#define REPRODUCE
static struct page *pages[NR_PAGES];
static void __iomem *map[NR_PAGES];
int init_module(void)
{
int i;
for (i = 0; i < NR_PAGES; i++) {
pages[i] = alloc_pages(GFP_KERNEL|__GFP_NOWARN, MAX_ORDER-1);
if (!pages[i])
break;
__SetPageReserved(pages[i]);
#ifdef REPRODUCE
map[i] = ioremap(page_to_phys(pages[i]), 1L<<(MAX_ORDER-1));
WARN_ON_ONCE(!map[i]);
#endif
}
return 0;
}
void cleanup_module(void)
{
int i;
for (i = 0; i < NR_PAGES; i++) {
if (map[i])
iounmap(map[i]);
if (!pages[i])
break;
__ClearPageReserved(pages[i]);
__free_pages(pages[i], MAX_ORDER-1);
}
}
MODULE_LICENSE("GPL");
==
Andrea Arcangeli (1):
x86: restore the write back cache of reserved RAM in iounmap()
arch/x86/mm/ioremap.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
next reply other threads:[~2020-11-19 17:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-19 17:59 Andrea Arcangeli [this message]
2020-11-19 17:59 ` [PATCH 1/1] x86: restore the write back cache of reserved RAM in iounmap() Andrea Arcangeli
2020-11-19 21:01 ` Thomas Gleixner
2020-11-19 18:02 ` [PATCH 0/1] " Christoph Hellwig
2020-11-19 19:03 ` Andrea Arcangeli
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=20201119175902.17394-1-aarcange@redhat.com \
--to=aarcange@redhat.com \
--cc=ak@linux.intel.com \
--cc=aquini@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
/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