lkml.org 
[lkml]   [2015]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 09/19] x86, mpx: trace entry to bounds exception paths
On Mon, 18 May 2015, Dave Hansen wrote:
> From: Dave Hansen <dave.hansen@linux.intel.com>
>
> There are two basic things that can happen as the result of
> a bounds exception (#BR):
>
> 1. We allocate a new bounds table
> 2. We pass up a bounds exception to userspace.
>
> This patch adds a trace point for the case where we are
> passing the exception up to userspace with a signal.
>
> We are also explicit that we're printing out the inverse of
> the 'upper' that we encounter. If you want to filter, for
> instance, you need to ~ the value first. The reason we do
> this is because of how 'upper' is stored in the bounds table.
> If a pointer's range is:
>
> 0x1000 -> 0x2000
>
> it is stored in the bounds table as (32-bits here for brevity):
>
> lower: 0x00001000
> upper: 0xffffdfff
>
> That is so that an all 0's entry:
>
> lower: 0x00000000
> upper: 0x00000000
>
> corresponds to the "init" bounds which store a *range* of:
>
> 0x00000000 -> 0xffffffff
>
> That is, by far, the common case, and that lets us use the
> zero page, or deduplicate the memory, etc... The 'upper'
> stored in the table is gibberish to print by itself, so we
> print ~upper to get the *actual*, logical, human-readable
> value printed out.

Thanks for clarifying that!

> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>

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


\
 
 \ /
  Last update: 2015-05-19 10:41    [W:0.355 / U:0.420 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site