Messages in this thread | | | Date | Tue, 19 May 2015 10:17:17 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [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>
| |