linux-kernel - Re: [PATCH] Doc: x86: Fix typo in intel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 28 Jul 2015 10:07:36 -0700
From:	Randy Dunlap <rdunlap@...radead.org>
To:	Masanari Iida <standby24x7@...il.com>, qiaowei.ren@...el.com,
	linux-kernel@...r.kernel.org, dave.hansen@...ux.intel.com,
	corbet@....net, linux-doc@...r.kernel.org
Subject: Re: [PATCH] Doc: x86: Fix typo in intel_mpx.txt

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@...il.com>
> ---
>  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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/