linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Dave Hansen <dave@sr71.net>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	dave.hansen@linux.intel.com
Subject: Re: [PATCH 17/19] x86, mpx: rewrite unmap code
Date: Mon, 18 May 2015 23:55:24 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.11.1505182354430.4225@nanos> (raw)
In-Reply-To: <20150508185957.C657301B@viggo.jf.intel.com>

On Fri, 8 May 2015, Dave Hansen wrote:
> The MPX code needs to clear out bounds tables for memory which
> is no longer in use.  We do this when a userspace mapping is
> torn down (unmapped).
> 
> There are two modes:
> 1. An entire bounds table becomes unused, and can be freed
>    and its pointer removed from the bounds directory.  This
>    happens either when a large mapping is torn down, or when
>    a small mapping is torn down and it is the last mapping
>    "covered" by a bounds table.
> 2. Only part of a bounds table becomes unused, in which case
>    we free the backing memory as if MADV_DONTNEED was called.
> 
> The old code was a spaghetti mess of "edge" bounds tables
> where the edges were handled specially, even if we were
> unmapping an entire one.  Non-edge bounds tables are always
> fully unmapped, but share a different code path from the edge
> ones.  The old code had a bug where it was unmapping too much
> memory.  I worked on fixing it for two days and gave up.
> 
> I didn't write the original code.  I didn't particularly like
> it, but it worked, so I left it.  After my debug session, I
> realized it was undebuggagle *and* buggy, so out it went.
> 
> I also wrote a new unmapping test program which uncovers bugs
> pretty nicely.

Very appreciated. This is really readable now.

Reviewed-by: Thomas Gleixner <tglx@linutronix.de>

  reply	other threads:[~2015-05-18 21:55 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-08 18:59 [PATCH 00/19] x86, mpx updates for 4.2 (take 6) Dave Hansen
2015-05-08 18:59 ` [PATCH 01/19] x86, mpx, xsave: fix up bad get_xsave_addr() assumptions Dave Hansen
2015-05-18 19:34   ` Thomas Gleixner
2015-05-08 18:59 ` [PATCH 02/19] x86, fpu: wrap get_xsave_addr() to make it safer Dave Hansen
2015-05-18 19:38   ` Thomas Gleixner
2015-05-18 19:42     ` Thomas Gleixner
2015-05-08 18:59 ` [PATCH 03/19] x86, mpx: use new tsk_get_xsave_addr() Dave Hansen
2015-05-18 20:36   ` Thomas Gleixner
2015-05-19  0:01     ` Dave Hansen
2015-05-08 18:59 ` [PATCH 04/19] x86, mpx: cleanup: do not pass task around when unnecessary Dave Hansen
2015-05-18 20:38   ` Thomas Gleixner
2015-05-08 18:59 ` [PATCH 05/19] x86, mpx: remove redundant MPX_BNDCFG_ADDR_MASK Dave Hansen
2015-05-18 20:38   ` Thomas Gleixner
2015-05-08 18:59 ` [PATCH 06/19] x86, mpx: we do not allocate the bounds directory Dave Hansen
2015-05-18 20:43   ` Thomas Gleixner
2015-05-08 18:59 ` [PATCH 07/19] x86, mpx: boot-time disable Dave Hansen
2015-05-18 20:45   ` Thomas Gleixner
2015-05-08 18:59 ` [PATCH 08/19] x86, mpx: trace #BR exceptions Dave Hansen
2015-05-18 21:00   ` Thomas Gleixner
2015-05-08 18:59 ` [PATCH 10/19] x86, mpx: trace ranged MPX operations Dave Hansen
2015-05-18 21:04   ` Thomas Gleixner
2015-05-08 18:59 ` [PATCH 09/19] x86, mpx: trace entry to bounds exception paths Dave Hansen
2015-05-18 20:58   ` Thomas Gleixner
2015-05-18 23:06     ` Dave Hansen
2015-05-18 23:35       ` Thomas Gleixner
2015-05-08 18:59 ` [PATCH 11/19] x86, mpx: trace allocation of new bounds tables Dave Hansen
2015-05-18 21:04   ` Thomas Gleixner
2015-05-08 18:59 ` [PATCH 12/19] x86: make is_64bit_mm() widely available Dave Hansen
2015-05-18 21:06   ` Thomas Gleixner
2015-05-08 18:59 ` [PATCH 14/19] x86, mpx: new directory entry to addr helper Dave Hansen
2015-05-18 21:10   ` Thomas Gleixner
2015-05-08 18:59 ` [PATCH 13/19] x86, mpx: Add temporary variable to reduce masking Dave Hansen
2015-05-18 21:07   ` Thomas Gleixner
2015-05-08 18:59 ` [PATCH 15/19] x86, mpx: do 32-bit-only cmpxchg for 32-bit apps Dave Hansen
2015-05-18 21:22   ` Thomas Gleixner
2015-05-08 18:59 ` [PATCH 16/19] x86, mpx: support 32-bit binaries on 64-bit kernel Dave Hansen
2015-05-18 21:53   ` Thomas Gleixner
2015-05-18 23:29     ` Dave Hansen
2015-05-18 23:37       ` Thomas Gleixner
2015-05-08 18:59 ` [PATCH 17/19] x86, mpx: rewrite unmap code Dave Hansen
2015-05-18 21:55   ` Thomas Gleixner [this message]
2015-05-08 18:59 ` [PATCH 18/19] x86, mpx: do not count MPX VMAs as neighbors when unmapping Dave Hansen
2015-05-18 21:54   ` Thomas Gleixner
2015-05-08 18:59 ` [PATCH 19/19] x86, mpx: allow mixed binaries again Dave Hansen
2015-05-18 21:55   ` Thomas Gleixner
2015-05-19  6:25 [PATCH 00/19] x86, mpx updates for 4.2 (take 7) Dave Hansen
2015-05-19  6:25 ` [PATCH 17/19] x86, mpx: rewrite unmap code Dave Hansen
2015-05-27 18:36 [PATCH 00/19] x86, mpx updates for 4.2 (take 8) Dave Hansen
2015-05-27 18:36 ` [PATCH 17/19] x86, mpx: rewrite unmap code Dave Hansen
2015-06-07 18:37 [PATCH 00/19] x86, mpx updates for 4.2 (take 9) Dave Hansen
2015-06-07 18:37 ` [PATCH 17/19] x86, mpx: rewrite unmap code Dave Hansen

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=alpine.DEB.2.11.1505182354430.4225@nanos \
    --to=tglx@linutronix.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=dave@sr71.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=x86@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;
as well as URLs for NNTP newsgroup(s).