On Mon, 18 May 2015, Dave Hansen wrote: > From: Dave Hansen <dave.han...@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.han...@linux.intel.com> Reviewed-by: Thomas Gleixner <t...@linutronix.de> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
