From: ebiederm@xmission.com (Eric W. Biederman)
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Szabolcs Nagy <szabolcs.nagy@arm.com>,
Richard Earnshaw <Richard.Earnshaw@arm.com>,
Kevin Brodsky <kevin.brodsky@arm.com>,
Andrey Konovalov <andreyknvl@google.com>,
Linux-MM <linux-mm@kvack.org>,
linux-arch <linux-arch@vger.kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH 12/22] arm64: mte: Add specific SIGSEGV codes
Date: Tue, 17 Dec 2019 14:06:01 -0600 [thread overview]
Message-ID: <877e2ura3a.fsf@x220.int.ebiederm.org> (raw)
Message-ID: <20191217200601.ePEYOIpnfbL9zxs2hATEXBzRGdj1-Wyesg2NE7sZZvE@z> (raw)
In-Reply-To: <20191217174808.GM5624@arrakis.emea.arm.com> (Catalin Marinas's message of "Tue, 17 Dec 2019 17:48:10 +0000")
Catalin Marinas <catalin.marinas@arm.com> writes:
> Hi Eric,
>
> On Thu, Dec 12, 2019 at 12:26:41PM -0600, Eric W. Biederman wrote:
>> Arnd Bergmann <arnd@arndb.de> writes:
>> > On Wed, Dec 11, 2019 at 7:40 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
>> >>
>> >> From: Vincenzo Frascino <vincenzo.frascino@arm.com>
>> >>
>> >> Add MTE-specific SIGSEGV codes to siginfo.h.
>> >>
>> >> Note that the for MTE we are reusing the same SPARC ADI codes because
>> >> the two functionalities are similar and they cannot coexist on the same
>> >> system.
>>
>> Please Please Please don't do that.
>>
>> It is actively harmful to have architecture specific si_code values.
>> As it makes maintenance much more difficult.
>>
>> Especially as the si_codes are part of union descrimanator.
>>
>> If your functionality is identical reuse the numbers otherwise please
>> just select the next numbers not yet used.
>
> It makes sense.
>
>> We have at least 256 si_codes per signal 2**32 if we really need them so
>> there is no need to be reuse numbers.
>>
>> The practical problem is that architecture specific si_codes start
>> turning kernel/signal.c into #ifdef soup, and we loose a lot of
>> basic compile coverage because of that. In turn not compiling the code
>> leads to bit-rot in all kinds of weird places.
>
> Fortunately for MTE we don't need to change kernel/signal.c. It's
> sufficient to call force_sig_fault() from the arch code with the
> corresponding signo, code and fault address.
Hooray for force_sig_fault at keeping people honest about which
parameters they are passing.
So far it looks like it is just BUS_MCEERR_AR, BUS_MCEERR_AO,
SEGV_BNDERR, and SEGV_PKUERR that are the really confusing ones,
as they go beyond the ordinary force_sig_fault layout.
But we really do need the knowledge of how all of the cases are encoded
or things can get very confusing. Especially when mixing 32bit and
64bit code.
>> p.s. As for coexistence there is always the possibility that one chip
>> in a cpu family does supports one thing and another chip in a cpu
>> family supports another. So userspace may have to cope with the
>> situation even if an individual chip doesn't.
>>
>> I remember a similar case where sparc had several distinct page table
>> formats and we had a single kernel that had to cope with them all.
>
> We have such fun on ARM as well with the big.LITTLE systems where not
> all CPUs support the same features. For example, MTE is only enabled
> once all the secondary CPUs have booted and confirmed to have the
> feature.
Which all makes it possible that the alternative to MTE referenced as
ADI might show up in some future ARM chip. Which really makes reusing
the numbers a bad idea.
Not that I actually recall what any of this functionality actually is,
but I can tell when people are setting themselves of for a challenge
unnecessarily.
Eric
next prev parent reply other threads:[~2019-12-17 20:07 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-11 18:40 [PATCH 00/22] arm64: Memory Tagging Extension user-space support Catalin Marinas
2019-12-11 18:40 ` Catalin Marinas
2019-12-11 18:40 ` [PATCH 01/22] mm: Reserve asm-generic prot flags 0x10 and 0x20 for arch use Catalin Marinas
2019-12-11 18:40 ` Catalin Marinas
2019-12-11 19:26 ` Arnd Bergmann
2019-12-11 19:26 ` Arnd Bergmann
2019-12-11 18:40 ` [PATCH 02/22] kbuild: Add support for 'as-instr' to be used in Kconfig files Catalin Marinas
2019-12-11 18:40 ` Catalin Marinas
2019-12-12 5:03 ` Masahiro Yamada
2019-12-12 5:03 ` Masahiro Yamada
2019-12-11 18:40 ` [PATCH 03/22] arm64: alternative: Allow alternative_insn to always issue the first instruction Catalin Marinas
2019-12-11 18:40 ` Catalin Marinas
2019-12-11 18:40 ` [PATCH 04/22] arm64: Use macros instead of hard-coded constants for MAIR_EL1 Catalin Marinas
2019-12-11 18:40 ` Catalin Marinas
2019-12-11 18:40 ` [PATCH 05/22] arm64: mte: system register definitions Catalin Marinas
2019-12-11 18:40 ` Catalin Marinas
2019-12-11 18:40 ` [PATCH 06/22] arm64: mte: CPU feature detection and initial sysreg configuration Catalin Marinas
2019-12-11 18:40 ` Catalin Marinas
2019-12-11 18:40 ` [PATCH 07/22] arm64: mte: Use Normal Tagged attributes for the linear map Catalin Marinas
2019-12-11 18:40 ` Catalin Marinas
2019-12-11 18:40 ` [PATCH 08/22] arm64: mte: Assembler macros and default architecture for .S files Catalin Marinas
2019-12-11 18:40 ` Catalin Marinas
2019-12-11 18:40 ` [PATCH 09/22] arm64: mte: Tags-aware clear_page() implementation Catalin Marinas
2019-12-11 18:40 ` Catalin Marinas
2019-12-11 18:40 ` [PATCH 10/22] arm64: mte: Tags-aware copy_page() implementation Catalin Marinas
2019-12-11 18:40 ` Catalin Marinas
2019-12-11 18:40 ` [PATCH 11/22] arm64: Tags-aware memcmp_pages() implementation Catalin Marinas
2019-12-11 18:40 ` Catalin Marinas
2019-12-11 18:40 ` [PATCH 12/22] arm64: mte: Add specific SIGSEGV codes Catalin Marinas
2019-12-11 18:40 ` Catalin Marinas
2019-12-11 19:31 ` Arnd Bergmann
2019-12-11 19:31 ` Arnd Bergmann
2019-12-12 9:34 ` Catalin Marinas
2019-12-12 9:34 ` Catalin Marinas
2019-12-12 18:26 ` Eric W. Biederman
2019-12-12 18:26 ` Eric W. Biederman
2019-12-17 17:48 ` Catalin Marinas
2019-12-17 17:48 ` Catalin Marinas
2019-12-17 20:06 ` Eric W. Biederman [this message]
2019-12-17 20:06 ` Eric W. Biederman
2019-12-11 18:40 ` [PATCH 13/22] arm64: mte: Handle synchronous and asynchronous tag check faults Catalin Marinas
2019-12-11 18:40 ` Catalin Marinas
2019-12-14 1:43 ` Peter Collingbourne
2019-12-14 1:43 ` Peter Collingbourne
2019-12-17 18:01 ` Catalin Marinas
2019-12-17 18:01 ` Catalin Marinas
2019-12-20 1:36 ` [PATCH] arm64: mte: Do not service syscalls after async tag fault Peter Collingbourne
2019-12-20 1:36 ` Peter Collingbourne
2020-02-12 11:09 ` Catalin Marinas
2020-02-18 21:59 ` Peter Collingbourne
2020-02-19 16:16 ` Catalin Marinas
2019-12-11 18:40 ` [PATCH 14/22] mm: Introduce arch_calc_vm_flag_bits() Catalin Marinas
2019-12-11 18:40 ` Catalin Marinas
2019-12-11 18:40 ` [PATCH 15/22] arm64: mte: Add PROT_MTE support to mmap() and mprotect() Catalin Marinas
2019-12-11 18:40 ` Catalin Marinas
2020-01-21 22:06 ` Peter Collingbourne
2019-12-11 18:40 ` [PATCH 16/22] mm: Introduce arch_validate_flags() Catalin Marinas
2019-12-11 18:40 ` Catalin Marinas
2019-12-11 18:40 ` [PATCH 17/22] arm64: mte: Validate the PROT_MTE request via arch_validate_flags() Catalin Marinas
2019-12-11 18:40 ` Catalin Marinas
2019-12-11 18:40 ` [PATCH 18/22] mm: Allow arm64 mmap(PROT_MTE) on RAM-based files Catalin Marinas
2019-12-11 18:40 ` Catalin Marinas
2019-12-11 18:40 ` [PATCH 19/22] arm64: mte: Allow user control of the tag check mode via prctl() Catalin Marinas
2019-12-11 18:40 ` Catalin Marinas
2019-12-19 20:32 ` Peter Collingbourne
2019-12-19 20:32 ` Peter Collingbourne
2019-12-20 1:48 ` [PATCH] arm64: mte: Clear SCTLR_EL1.TCF0 on exec Peter Collingbourne
2019-12-20 1:48 ` Peter Collingbourne
2020-02-12 17:03 ` Catalin Marinas
2019-12-27 14:34 ` [PATCH 19/22] arm64: mte: Allow user control of the tag check mode via prctl() Kevin Brodsky
2019-12-27 14:34 ` Kevin Brodsky
2020-02-12 11:45 ` Catalin Marinas
2019-12-11 18:40 ` [PATCH 20/22] arm64: mte: Allow user control of the excluded tags " Catalin Marinas
2019-12-11 18:40 ` Catalin Marinas
2019-12-16 14:20 ` Kevin Brodsky
2019-12-16 14:20 ` Kevin Brodsky
2019-12-16 17:30 ` Peter Collingbourne
2019-12-16 17:30 ` Peter Collingbourne
2019-12-17 17:56 ` Catalin Marinas
2019-12-17 17:56 ` Catalin Marinas
2020-06-22 17:17 ` Catalin Marinas
2020-06-22 19:00 ` Peter Collingbourne
2020-06-23 16:42 ` Catalin Marinas
2019-12-11 18:40 ` [PATCH 21/22] arm64: mte: Kconfig entry Catalin Marinas
2019-12-11 18:40 ` Catalin Marinas
2019-12-11 18:40 ` [PATCH 22/22] arm64: mte: Add Memory Tagging Extension documentation Catalin Marinas
2019-12-11 18:40 ` Catalin Marinas
2019-12-24 15:03 ` Kevin Brodsky
2019-12-24 15:03 ` Kevin Brodsky
2019-12-13 18:05 ` [PATCH 00/22] arm64: Memory Tagging Extension user-space support Peter Collingbourne
2019-12-13 18:05 ` Peter Collingbourne
2020-02-13 11:23 ` 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=877e2ura3a.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=Richard.Earnshaw@arm.com \
--cc=andreyknvl@google.com \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=kevin.brodsky@arm.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=maz@kernel.org \
--cc=szabolcs.nagy@arm.com \
--cc=vincenzo.frascino@arm.com \
--cc=viro@zeniv.linux.org.uk \
--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 NNTP newsgroup(s).