From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: xen-devel@lists.xen.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
min.he@intel.com, Jan Beulich <jbeulich@suse.com>,
yi.z.zhang@intel.com
Subject: [PATCH v2 1/2] x86/mm: fix a potential race condition in map_pages_to_xen().
Date: Fri, 10 Nov 2017 15:18:05 +0800 [thread overview]
Message-ID: <1510298286-30952-1-git-send-email-yu.c.zhang@linux.intel.com> (raw)
From: Min He <min.he@intel.com>
In map_pages_to_xen(), a L2 page table entry may be reset to point to
a superpage, and its corresponding L1 page table need be freed in such
scenario, when these L1 page table entries are mapping to consecutive
page frames and having the same mapping flags.
However, variable `pl1e` is not protected by the lock before L1 page table
is enumerated. A race condition may happen if this code path is invoked
simultaneously on different CPUs.
For example, `pl1e` value on CPU0 may hold an obsolete value, pointing
to a page which has just been freed on CPU1. Besides, before this page
is reused, it will still be holding the old PTEs, referencing consecutive
page frames. Consequently the `free_xen_pagetable(l2e_to_l1e(ol2e))` will
be triggered on CPU0, resulting the unexpected free of a normal page.
This patch fixes the potential race condition by protecting the `pl1e`
with the lock, and checking the PSE flag of the `pl2e`.
Note: PSE flag of `pl3e` is also checked before its re-consolidation,
for the same reason we do for `pl2e` - we cannot presume the contents
of the target superpage.
Signed-off-by: Min He <min.he@intel.com>
Signed-off-by: Yi Zhang <yi.z.zhang@intel.com>
Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
---
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Changes in v2:
According to comments from Jan Beulich,
- check PSE of pl2e and pl3e, and skip the re-consolidation if set.
- commit message changes, e.g. add "From :" tag etc.
- code style changes.
- introduce a seperate patch to resolve the similar issue in
modify_xen_mappings().
---
xen/arch/x86/mm.c | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index a20fdca..47855fb 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4844,9 +4844,19 @@ int map_pages_to_xen(
{
unsigned long base_mfn;
- pl1e = l2e_to_l1e(*pl2e);
if ( locking )
spin_lock(&map_pgdir_lock);
+
+ /* Skip the re-consolidation if it's done on another CPU. */
+ if ( l2e_get_flags(*pl2e) & _PAGE_PSE )
+ {
+ if ( locking )
+ spin_unlock(&map_pgdir_lock);
+ goto check_l3;
+ }
+
+ ol2e = *pl2e;
+ pl1e = l2e_to_l1e(ol2e);
base_mfn = l1e_get_pfn(*pl1e) & ~(L1_PAGETABLE_ENTRIES - 1);
for ( i = 0; i < L1_PAGETABLE_ENTRIES; i++, pl1e++ )
if ( (l1e_get_pfn(*pl1e) != (base_mfn + i)) ||
@@ -4854,7 +4864,6 @@ int map_pages_to_xen(
break;
if ( i == L1_PAGETABLE_ENTRIES )
{
- ol2e = *pl2e;
l2e_write_atomic(pl2e, l2e_from_pfn(base_mfn,
l1f_to_lNf(flags)));
if ( locking )
@@ -4880,6 +4889,15 @@ int map_pages_to_xen(
if ( locking )
spin_lock(&map_pgdir_lock);
+
+ /* Skip the re-consolidation if it's done on another CPU. */
+ if ( l3e_get_flags(*pl3e) & _PAGE_PSE )
+ {
+ if ( locking )
+ spin_unlock(&map_pgdir_lock);
+ continue;
+ }
+
ol3e = *pl3e;
pl2e = l3e_to_l2e(ol3e);
base_mfn = l2e_get_pfn(*pl2e) & ~(L2_PAGETABLE_ENTRIES *
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next reply other threads:[~2017-11-10 7:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-10 7:18 Yu Zhang [this message]
2017-11-10 7:18 ` [PATCH v2 2/2] x86/mm: fix a potential race condition in modify_xen_mappings() Yu Zhang
2017-11-10 9:57 ` Jan Beulich
2017-11-10 14:02 ` Yu Zhang
2017-11-13 9:33 ` Jan Beulich
2017-11-10 9:49 ` [PATCH v2 1/2] x86/mm: fix a potential race condition in map_pages_to_xen() Jan Beulich
2017-11-10 14:05 ` Yu Zhang
2017-11-13 9:31 ` Jan Beulich
2017-11-13 10:34 ` Yu Zhang
2017-11-13 11:06 ` Jan Beulich
2017-11-13 11:22 ` Julien Grall
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=1510298286-30952-1-git-send-email-yu.c.zhang@linux.intel.com \
--to=yu.c.zhang@linux.intel.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=min.he@intel.com \
--cc=xen-devel@lists.xen.org \
--cc=yi.z.zhang@intel.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).