On 07/28/15 04:00, Masanari Iida wrote:
> This patch fix some spelling typos in intel_mpx.txt
>
> Signed-off-by: Masanari Iida <standby24x7@xxxxxxxxx>
> ---
> Documentation/x86/intel_mpx.txt | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/x86/intel_mpx.txt b/Documentation/x86/intel_mpx.txt
> index 818518a..5cc98d5 100644
> --- a/Documentation/x86/intel_mpx.txt
> +++ b/Documentation/x86/intel_mpx.txt
> @@ -45,7 +45,7 @@ is how we expect the compiler, application and kernel to work together.
> MPX-instrumented.
> 3) The kernel detects that the CPU has MPX, allows the new prctl() to
> succeed, and notes the location of the bounds directory. Userspace is
> - expected to keep the bounds directory at that locationWe note it
> + expected to keep the bounds directory at that location We note it
at that location. We
> instead of reading it each time because the 'xsave' operation needed
> to access the bounds directory register is an expensive operation.
> 4) If the application needs to spill bounds out of the 4 registers, it
> @@ -151,7 +151,7 @@ A: This would work if we could hook the site of each and every memory
> these calls.
>
> Q: Could a bounds fault be handed to userspace and the tables allocated
> - there in a signal handler intead of in the kernel?
> + there in a signal handler instead of in the kernel?
> A: mmap() is not on the list of safe async handler functions and even
> if mmap() would work it still requires locking or nasty tricks to
> keep track of the allocation state there.
> @@ -167,7 +167,7 @@ If a #BR is generated due to a bounds violation caused by MPX.
> We need to decode MPX instructions to get violation address and
> set this address into extended struct siginfo.
>
> -The _sigfault feild of struct siginfo is extended as follow:
> +The _sigfault field of struct siginfo is extended as follow:
as follows:
>
> 87 /* SIGILL, SIGFPE, SIGSEGV, SIGBUS */
> 88 struct {
> @@ -240,5 +240,5 @@ them at the same bounds table.
> This is allowed architecturally. See more information "Intel(R) Architecture
> Instruction Set Extensions Programming Reference" (9.3.4).
>
> -However, if users did this, the kernel might be fooled in to unmaping an
> +However, if users did this, the kernel might be fooled in to unmapping an
into
> in-use bounds table since it does not recognize sharing.
>
--
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
