arm64: documentation: tighten up tagged pointer documentation
authorWill Deacon <will.deacon@arm.com>
Tue, 17 Sep 2013 10:46:23 +0000 (11:46 +0100)
committerCatalin Marinas <catalin.marinas@arm.com>
Fri, 20 Sep 2013 08:56:06 +0000 (09:56 +0100)
Commit d50240a5f6ce ("arm64: mm: permit use of tagged pointers at EL0")
added support for tagged pointers in userspace, but the corresponding
update to Documentation/ contained some imprecise statements.

This patch fixes up some minor ambiguities in the text, hopefully making
it more clear about exactly what the kernel expects from user virtual
addresses.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Documentation/arm64/tagged-pointers.txt

index 264e9841563aa6ebb162b545fb3442b85f00c38b..d9995f1f51b3eb9e678a557a471e4d387db49ca8 100644 (file)
@@ -18,17 +18,17 @@ this byte for application use, with the following caveats:
            parameters containing user virtual addresses *must* have
            their top byte cleared before trapping to the kernel.
 
-       (2) Tags are not guaranteed to be preserved when delivering
-           signals. This means that signal handlers in applications
-           making use of tags cannot rely on the tag information for
-           user virtual addresses being maintained for fields inside
-           siginfo_t. One exception to this rule is for signals raised
-           in response to debug exceptions, where the tag information
+       (2) Non-zero tags are not preserved when delivering signals.
+           This means that signal handlers in applications making use
+           of tags cannot rely on the tag information for user virtual
+           addresses being maintained for fields inside siginfo_t.
+           One exception to this rule is for signals raised in response
+           to watchpoint debug exceptions, where the tag information
            will be preserved.
 
        (3) Special care should be taken when using tagged pointers,
            since it is likely that C compilers will not hazard two
-           addresses differing only in the upper bits.
+           virtual addresses differing only in the upper byte.
 
 The architecture prevents the use of a tagged PC, so the upper byte will
 be set to a sign-extension of bit 55 on exception return.