From: Paul Eggert <eggert@cs.ucla.edu>
To: Szabolcs Nagy <szabolcs.nagy@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>
Cc: 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: Thu, 20 Aug 2020 10:27:43 -0700 [thread overview]
Message-ID: <80a8937b-6e48-44ce-221c-84c6d27b211d@cs.ucla.edu> (raw)
In-Reply-To: <20200820164313.GL29343@arm.com>
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.
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.
This whole thing reminds me of the ancient IBM S/360 mainframes that were
documented to ignore the top 8 bits of 32-bit addresses merely because a single
model (the IBM 360/30, circa 1965) was so underpowered that it couldn't quickly
check that the top bits were zero. This has caused countless software hassles
over the years. Even today, the IBM z-Series hardware and software still
supports 24-bit addressing mode because of that early-1960s design mistake. See:
Mashey JR. The Long Road to 64 Bits. ACM Queue. 2006-10-10.
https://queue.acm.org/detail.cfm?id=1165766
next prev parent reply other threads:[~2020-08-20 17:27 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 [this message]
2020-08-22 11:31 ` Catalin Marinas
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=80a8937b-6e48-44ce-221c-84c6d27b211d@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--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=catalin.marinas@arm.com \
--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).