|author||Will Deacon <email@example.com>||2013-09-17 11:46:23 +0100|
|committer||Alex Shi <firstname.lastname@example.org>||2014-04-14 12:41:15 +0800|
arm64: documentation: tighten up tagged pointer documentationv3.10/topic/tagged-pointers
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. Change-Id: I7df342e01d5253ccacb3847449940892768d7e07 Signed-off-by: Will Deacon <email@example.com> Signed-off-by: Catalin Marinas <firstname.lastname@example.org> (cherry picked from commit 7a18e70688223a37ba4c8cf5edd313e8d1bb680d) Signed-off-by: Alex Shi <email@example.com>
1 files changed, 7 insertions, 7 deletions
diff --git a/Documentation/arm64/tagged-pointers.txt b/Documentation/arm64/tagged-pointers.txt
index 264e984..d9995f1 100644
@@ -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.