From: Catalin Marinas <catalin.marinas@arm.com>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: Szabolcs Nagy <szabolcs.nagy@arm.com>,
linux-arch@vger.kernel.org,
Richard Earnshaw <Richard.Earnshaw@arm.com>,
nd@arm.com, libc-alpha@sourceware.org,
Will Deacon <will@kernel.org>,
Andrey Konovalov <andreyknvl@google.com>,
Kevin Brodsky <kevin.brodsky@arm.com>,
linux-mm@kvack.org, Matthew Malcomson <Matthew.Malcomson@arm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Peter Collingbourne <pcc@google.com>,
Dave Martin <Dave.Martin@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v7 29/29] arm64: mte: Add Memory Tagging Extension documentation
Date: Sat, 22 Aug 2020 12:31:38 +0100 [thread overview]
Message-ID: <20200822113138.GC16635@gaia> (raw)
In-Reply-To: <80a8937b-6e48-44ce-221c-84c6d27b211d@cs.ucla.edu>
On Thu, Aug 20, 2020 at 10:27:43AM -0700, Paul Eggert wrote:
> On 8/20/20 9:43 AM, Szabolcs Nagy wrote:
> > the compat issue with this is existing code
> > using pointer top bits which i assume faults
> > when dereferenced with the mte checks enabled.
> > (although this should be very rare since
> > top byte ignore on deref is aarch64 specific.)
>
> Does anyone know of significant aarch64-specific application code that
> depends on top byte ignore? I would think it's so rare (nonexistent?) as to
> not be worth worrying about.
Apart from the LLVM hwasan feature, I'm not aware of code relying on the
top byte ignore. There were discussions in the past to use it with some
JITs but I'm not sure they ever materialised.
I think the Mozilla JS engine uses (used?) additional bits on top of a
pointer but they are masked out before the access.
> Even in the bad old days when Emacs used pointer top bits for typechecking,
> it carefully removed those bits before dereferencing. Any other
> reasonably-portable application would have to do the same of course.
I agree.
--
Catalin
next prev parent reply other threads:[~2020-08-22 11:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200727163634.GO7127@arm.com>
[not found] ` <20200728110758.GA21941@arm.com>
[not found] ` <20200728145350.GR7127@arm.com>
[not found] ` <20200728195957.GA31698@gaia>
[not found] ` <20200803124309.GC14398@arm.com>
[not found] ` <20200807151906.GM6750@gaia>
[not found] ` <20200810141309.GK14398@arm.com>
[not found] ` <20200811172038.GB1429@gaia>
[not found] ` <20200812124520.GP14398@arm.com>
[not found] ` <20200819095453.GA86@DESKTOP-O1885NU.localdomain>
2020-08-20 16:43 ` Szabolcs Nagy
2020-08-20 17:27 ` Paul Eggert
2020-08-22 11:31 ` Catalin Marinas [this message]
2020-08-22 11:28 ` Catalin Marinas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200822113138.GC16635@gaia \
--to=catalin.marinas@arm.com \
--cc=Dave.Martin@arm.com \
--cc=Matthew.Malcomson@arm.com \
--cc=Richard.Earnshaw@arm.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@google.com \
--cc=eggert@cs.ucla.edu \
--cc=kevin.brodsky@arm.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=nd@arm.com \
--cc=pcc@google.com \
--cc=szabolcs.nagy@arm.com \
--cc=vincenzo.frascino@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).