Thread (13 messages) 13 messages, 5 authors, 2019-08-23

Re: [PATCH v9 3/3] arm64: Relax Documentation/arm64/tagged-pointers.rst

From: Dave Martin <Dave.Martin@arm.com>
Date: 2019-08-23 16:32:57
Also in: linux-arm-kernel, linux-doc, linux-mm

On Fri, Aug 23, 2019 at 05:19:13PM +0100, Catalin Marinas wrote:
On Thu, Aug 22, 2019 at 05:37:23PM +0100, Dave P Martin wrote:
quoted
On Thu, Aug 22, 2019 at 04:55:32PM +0100, Catalin Marinas wrote:
quoted
On Wed, Aug 21, 2019 at 07:46:51PM +0100, Dave P Martin wrote:
[...]
quoted
quoted
quoted
sigaltstack() is interesting, since we don't support tagged stacks.
We should support tagged SP with the new ABI as they'll be required for
MTE. sigaltstack() and clone() are the two syscalls that come to mind
here.
quoted
Do we keep the ss_sp tag in the kernel, but squash it when delivering
a signal to the alternate stack?
We don't seem to be doing any untagging, so we just just use whatever
the caller asked for. We may need a small test to confirm.
If we want to support tagged SP, then I guess we shouldn't be squashing
the tag anywhere.  A test for that would be sensible to have.
I hacked the sas.c kselftest to use a tagged stack and works fine, the
SP register has a tagged address on the signal handler.
Cool...

[...]
quoted
quoted
quoted
There is no foolproof rule, unless we can rewrite history...
I would expect the norm to be the preservation of tags with a few
exceptions. The only ones I think where we won't preserve the tags are
mmap, mremap, brk (apart from the signal stuff already mentioned in the
current tagged-pointers.rst doc).

So I can remove this paragraph altogether and add a note in part 3 of
the tagged-address-abi.rst document that mmap/mremap/brk do not preserve
the tag information.
Deleting text is always a good idea ;)
I'm going this route ;).
[reply deleted]

Cheers
---Dave
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help