linux-kernel - [tip:x86/fpu] x86/mpx: Do not count MPX VMAs as neighbors when unmapping

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <tip-bea03c50b871a2fa922f31ad7c9993bb4fc7b192@git.kernel.org>
Date:	Tue, 9 Jun 2015 05:35:59 -0700
From:	tip-bot for Dave Hansen <tipbot@...or.com>
To:	linux-tip-commits@...r.kernel.org
Cc:	akpm@...ux-foundation.org, hpa@...or.com,
	torvalds@...ux-foundation.org, peterz@...radead.org,
	mingo@...nel.org, linux-kernel@...r.kernel.org, tglx@...utronix.de,
	dave@...1.net, dave.hansen@...ux.intel.com
Subject: [tip:x86/fpu] x86/mpx:
  Do not count MPX VMAs as neighbors when unmapping

Commit-ID:  bea03c50b871a2fa922f31ad7c9993bb4fc7b192
Gitweb:     http://git.kernel.org/tip/bea03c50b871a2fa922f31ad7c9993bb4fc7b192
Author:     Dave Hansen <dave.hansen@...ux.intel.com>
AuthorDate: Sun, 7 Jun 2015 11:37:06 -0700
Committer:  Ingo Molnar <mingo@...nel.org>
CommitDate: Tue, 9 Jun 2015 12:24:34 +0200

x86/mpx: Do not count MPX VMAs as neighbors when unmapping

The comment pretty much says it all.

I wrote a test program that does lots of random allocations
and forces bounds tables to be created.  It came up with a
layout like this:

  ....   | BOUNDS DIRECTORY ENTRY COVERS |  ....
         |    BOUNDS TABLE COVERS        |
|  BOUNDS TABLE |  REAL ALLOC | BOUNDS TABLE |

Unmapping "REAL ALLOC" should have been able to free the
bounds table "covering" the "REAL ALLOC" because it was the
last real user.  But, the neighboring VMA bounds tables were
found, considered as real neighbors, and we declined to free
the bounds table covering the area.

Doing this over and over left a small but significant number
of these orphans.  Handling them is fairly straighforward.
All we have to do is walk the VMAs and skip all of the MPX
ones when looking for neighbors.

Signed-off-by: Dave Hansen <dave.hansen@...ux.intel.com>
Reviewed-by: Thomas Gleixner <tglx@...utronix.de>
Cc: Andrew Morton <akpm@...ux-foundation.org>
Cc: Dave Hansen <dave@...1.net>
Cc: H. Peter Anvin <hpa@...or.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Peter Zijlstra <peterz@...radead.org>
Link: http://lkml.kernel.org/r/20150607183706.A6BD90BF@viggo.jf.intel.com
Signed-off-by: Ingo Molnar <mingo@...nel.org>
---
 arch/x86/mm/mpx.c | 24 +++++++++++++++++++-----
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/arch/x86/mm/mpx.c b/arch/x86/mm/mpx.c
index 18fcf73..6233d51 100644
--- a/arch/x86/mm/mpx.c
+++ b/arch/x86/mm/mpx.c
@@ -937,16 +937,30 @@ static int try_unmap_single_bt(struct mm_struct *mm,
 	void __user *bde_vaddr;
 	int ret;
 	/*
+	 * We already unlinked the VMAs from the mm's rbtree so 'start'
+	 * is guaranteed to be in a hole. This gets us the first VMA
+	 * before the hole in to 'prev' and the next VMA after the hole
+	 * in to 'next'.
+	 */
+	next = find_vma_prev(mm, start, &prev);
+	/*
+	 * Do not count other MPX bounds table VMAs as neighbors.
+	 * Although theoretically possible, we do not allow bounds
+	 * tables for bounds tables so our heads do not explode.
+	 * If we count them as neighbors here, we may end up with
+	 * lots of tables even though we have no actual table
+	 * entries in use.
+	 */
+	while (next && is_mpx_vma(next))
+		next = next->vm_next;
+	while (prev && is_mpx_vma(prev))
+		prev = prev->vm_prev;
+	/*
 	 * We know 'start' and 'end' lie within an area controlled
 	 * by a single bounds table.  See if there are any other
 	 * VMAs controlled by that bounds table.  If there are not
 	 * then we can "expand" the are we are unmapping to possibly
 	 * cover the entire table.
-	 *
-	 * We already unliked the VMAs from the mm's rbtree so 'start'
-	 * is guaranteed to be in a hole. This gets us the first VMA
-	 * before the hole in to 'prev' and the next VMA after the hole
-	 * in to 'next'.
 	 */
 	next = find_vma_prev(mm, start, &prev);
 	if ((!prev || prev->vm_end <= bta_start_vaddr) &&
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/