From: ebiederm@xmission.com (Eric W. Biederman) To: Catalin Marinas <catalin.marinas@arm.com> Cc: linux-arch <linux-arch@vger.kernel.org>, Richard Earnshaw <Richard.Earnshaw@arm.com>, Arnd Bergmann <arnd@arndb.de>, Szabolcs Nagy <szabolcs.nagy@arm.com>, Marc Zyngier <maz@kernel.org>, Kevin Brodsky <kevin.brodsky@arm.com>, Linux-MM <linux-mm@kvack.org>, Al Viro <viro@zeniv.linux.org.uk>, Andrey Konovalov <andreyknvl@google.com>, Vincenzo Frascino <vincenzo.frascino@arm.com>, Will Deacon <will@kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org> 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) 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
WARNING: multiple messages have this Message-ID (diff)
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:06 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: linkBe 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).