Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756496AbcCaM3W (ORCPT ); Thu, 31 Mar 2016 08:29:22 -0400 Received: from mail-bl2on0096.outbound.protection.outlook.com ([65.55.169.96]:27472 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752259AbcCaM3U (ORCPT ); Thu, 31 Mar 2016 08:29:20 -0400 Authentication-Results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=caviumnetworks.com; Date: Thu, 31 Mar 2016 15:28:59 +0300 From: Yury Norov To: Mark Rutland CC: , , , , , , , Subject: Re: [RFC] [PATCH] arm64: survive after access to unimplemented register Message-ID: <20160331122859.GA27859@yury-N73SV> References: <1459391223-3826-1-git-send-email-ynorov@caviumnetworks.com> <20160331100547.GA26532@leverpostej> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20160331100547.GA26532@leverpostej> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [95.143.213.121] X-ClientProxiedBy: VI1PR02CA0031.eurprd02.prod.outlook.com (25.162.7.169) To DM2PR07MB624.namprd07.prod.outlook.com (10.141.177.154) X-MS-Office365-Filtering-Correlation-Id: 37b8b6d7-fd3a-43a6-aef9-08d35960136f X-Microsoft-Exchange-Diagnostics: 1;DM2PR07MB624;2:NgEh7oLI4ZCjkllhDvwQoKuKJE4nfkbhY+JcqmDp3ah0fVYFDFCXoW+XzzA54vbQlgV//DvJwlavf31cnYXzdqCWFkF70QY6N3S6pd3NyPNUAeiiPjp7ixRg+WJ2BokNCicC35IhcFnVrpqZGBcHdjx4hm8JeLOLnJrswH7cWrQcz8g2T6FFyaRI46pOP3Vi;3:v22O7w+BG7Yy9vcTNYi4ehId6KGDnTQW6jUOM/2n0qkQ9N1gfJtIbDRXjzEPjK/04vKkZgs3OpRBvzwGb6TobWL/dLJJ1mYVCRNwW8p6WCNEbhQo3cldRPNEuEneJTYN;25:4KyS+hMiU4A7tSVkLprCUZVa20RDzm3wtBfCjxervc48PcFA6MEwJSseIfo6vsJEJAjrUSRjBLpZpxAVIHV1KvBrS5GqXuihqlZ4sV782E1wGaM1bdWzSkURIvtLBNxAuPFH1yX2KCZxJ7Emb3rFDhxEEPHpYoXiBuGaPPJqP7FUqAr4ot45zndGTzMws/8PBEFGNFo0EeQtxBHCQBWOSTVyBvNb6nbKBf2v1fjgX5du7lC9y6qctJsqFsV0UBJ3v4dhSwRrR/l/poi4j2wgSj0QOdA0d6bScEJL6s7Wii25d4TyPX5QhCdKJhG04qTgPeQ0mKNyxRiDY0pDcKCzfMuK9IT1y4+B7ZxnKe2Nd3A= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR07MB624; X-Microsoft-Exchange-Diagnostics: 1;DM2PR07MB624;20:jodYfwofjUF0qOX5330g/OFmHE+PE1Y7IVTOHZuq0jmPJl55cy3Nnrj1DqrtTMN/WnzqYut/0InEo6bFshv/9PWpJyf3OUf9AvPc7LeqWGCUNZREOZ8A8/f3RY9XB2/6YSAyUbc7KsIpuXv2s376lXlC1DnnBZWom5dx3yqYwn3c96IpEYkpMtZfo52xSMBErahwe1pSIOjl8UF7wdnH4KHDA0+IhEmIvABo/CGRlbvZLL2OjEIX9LqQ7aMjHURqeW72c0kYJVyEWHScQrgfT+22jmvova/gngewvnH7uvXphYO7uVx5VrpQ/rpzNkys2iYqku8RFWhZ2y1piUvkod6APGUPp/mscvaiIInOviomZWyVF7K5Wr8CLg8g19rCpXPn6ZYoUaVYIIvcL+DCPuBUiduUzw/YUJ+93S75p+pZWApS8sF8OBIlIN/IH18BrzTtT8rn4ZWlQPJpHBPuBgqr0c04QROOlLTTghPid69m5Y/CSbrEDenx9BlLmvQsY0TyVZulQjWjy7A7P1H3pALjukVf47Gh/EJOSkowdWtHXFF++DsIdAXtXHJfTVpZtch8FcOfdcXWvMWTFpoIeZ7RWW3cHPv3FkNBTtbUcHE= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046);SRVR:DM2PR07MB624;BCL:0;PCL:0;RULEID:;SRVR:DM2PR07MB624; X-Microsoft-Exchange-Diagnostics: 1;DM2PR07MB624;4:sXrfed4QvruML2+Pt5+YvLJOhSLSW3LNL9WbwBLl1oNm1/CKFSMZMXpPUeezkIyR0P8x8qdh+hcGHI9Yb7CWt/pqC7me8V7DjpUI/peeCKiMHRCf3IZ5gjSJ4fD6N0Xp/0rdlYXd4t7BAquzNJu3N7Ndtch1cFM91X6Eu0GWXWqW4fk0uaOLOEe+Jnd28d73hVhoZ6JmIP00BUTwfAXcisH/K5ODaQe7cAte54V2OZilelBE/7jVjtwQ0ECmZHXyQjSY7kneGRsz1Nb6PvKqh1j7vcOw9WnK1XoAgOilCz+VQAqxK2ciWm9ei9Kwj+GoxhBCj3kRW3ncO1TkdgcBlOSqwA8hmf1mX199gr5y6wBwepOEGTJvTMzJBlcwF24b X-Forefront-PRVS: 0898A6E028 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(164054003)(24454002)(47776003)(81166005)(2906002)(42186005)(50986999)(54356999)(92566002)(66066001)(76176999)(33716001)(4326007)(46406003)(77096005)(575784001)(97756001)(189998001)(76506005)(23726003)(1076002)(1720100001)(1096002)(33656002)(15975445007)(5004730100002)(2950100001)(50466002)(19580405001)(586003)(3846002)(6116002)(19580395003)(110136002)(5008740100001)(21314002);DIR:OUT;SFP:1101;SCL:1;SRVR:DM2PR07MB624;H:localhost;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;DM2PR07MB624;23:Ol/nZ3GOIufuBpoJst9oQjnbnrvUiGxC/IggqqKCsq?= =?us-ascii?Q?t2DvcxeVdLH7gKz31EgoRfZQOH7E9cmcLgDtxomzN8xMJBDH5PeyJFfVUL5e?= =?us-ascii?Q?bWWl+QmoBlYlUXeA7PZAsnbF1+zPJDrMg0225tjWioXwioqlrfG1f/2u1LuF?= =?us-ascii?Q?+hjlt7RlacxWtpTpQPtuPFnMddT/zNQZn9eJJdl/bLb01i9KEMCbivsIRaKo?= =?us-ascii?Q?opgkz7OjT4XBCyKljTeXJI/dryQziwbLt3mQsZtP0EVsUXBPc3XuJHpIM6mW?= =?us-ascii?Q?ZmYCS/SEKaV8TVcmlwjEdKE3smWyAaigYhwZPJaaMXplYEs7Hcmjg13MclHh?= =?us-ascii?Q?VDUXhG36w3GqerK0fuSed8sCnrghwFFTCB3z1WTa7u1x1pzTnoK2wOd/uoOc?= =?us-ascii?Q?ly6O/NvY26HaqfkzYO9FWN7HyiaaUABwtsT8gRMNZOqNDlCte5oeM6T/RdOr?= =?us-ascii?Q?qPlThlcA1+AlJcE5AqIuYwKFE+T+QbExfPSVUIuLY+b7rb37kFYmlFs0gMRl?= =?us-ascii?Q?dkG0cTdRMywuFR7h9gIsRFCTqqsN4gFdtMjzC0+u2FQVvrqrfEZqNrFCwc4D?= =?us-ascii?Q?030M9OcbPQ8GEQ9VrPKLt4YKa8Ii4FJQo5njrrUj71YvWQS/ph4DaI7zCMvj?= =?us-ascii?Q?tuy3Tg+Gqfa2+qVvQR832rnxfj6Qkl7bAoWXj+sN+2U3KQPnve54jGQsYd42?= =?us-ascii?Q?RJiG5gzij+ah3ATkD7duIu7gx6CSdNFW9E9BjzoHL4TwRmRyNoQaGMRwQl9r?= =?us-ascii?Q?SK9VS5GSPaFv9cJdS5X2rlnmL6Exnv1OUhz2ZAqBC5cb+4bNzhrkpMz73IBq?= =?us-ascii?Q?PP9UFBql8TQ2b2oRvUBmB6cAIaf78nigMquXGTVZywFdhG59OmaTAOhDvLPj?= =?us-ascii?Q?ie6yM/O8WYHQj49P88zWiDODJpLjn9kZMsqAXLOpPAMozXaGHjemPKs9pXV+?= =?us-ascii?Q?7duLtwhpFh8o/dsZdWkA8j9qT9xpcYqF8r3Akkns2Bxt1xiQzffLGBMrmy1a?= =?us-ascii?Q?5vP8mPdfQoGl1nGXOKOguY?= X-Microsoft-Exchange-Diagnostics: 1;DM2PR07MB624;5:qUc3Yko2IQE7Cwa4r9PTNV84ae2/tPx53CwJnMubrTVZUH3rBB6PLDWdQ31tKvpAfriVj95qjQV7QhtKXQ9nuloOmeP6ikxM/Pb+pG7RpYvM6+v57u3LFZ6mASGXuusrqWxVDhuEmlVfmwJA/kdzJQ==;24:+fOY4U7H/VgwRyZQbuucz7eLzixMKlMZazy19y5cFLZNsich1zI0oCSyz6y+Nk+NQVUCWFhqOk5mHHxQqOyfoe+EShhQuHKsg/3f7DG/BTs= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Mar 2016 12:29:16.2815 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR07MB624 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 7609 Lines: 223 Hi Mark, On Thu, Mar 31, 2016 at 11:05:48AM +0100, Mark Rutland wrote: > On Thu, Mar 31, 2016 at 05:27:03AM +0300, Yury Norov wrote: > > Not all vendors implement all the system registers ARM specifies. > > The ID registers in question are precisely documented in the ARM ARM > (see table C5-6 in ARM DDI 0487A.i). Specifically, the ID space > ID_AA64MMFR2_EL1 now falls in to is listed as RAZ. > > Any deviation from this is an erratum, and needs to be handled as such > (e.g. listing in silicon-errata.txt). > > Does the issue affect ThunderX natively? Yes, Thunder is involved, but I cannot tell more due to NDA. And this error is not in silicon-errata.txt. I'll ask permission to share more details. > > Or has this only been seen with QEMU (in TCG mode), where the bug has > already been fixed? > > > So access them causes undefined instruction abort and then kernel > > panic. There are 3 ways to handle it we can figure out: > > - use conditional compilation and erratas; > > - use kernel patching; > > - inline fixups resolving the abort. > > > > Last option is more robust as it does not require additional efforts > > to support targers. It is looking reasonable because in many cases > > optional registers should be RAZ if not implemented. Special cases may > > be handled by underlying __read_cpuid() when needed. > > I don't think we should do this if the only affected implementations are > software emulators which can be patched (and have already been, in the > case of QEMU). > > In future it's very likely that early assembly code (potentially in > hypervisor context) will need to access ID registers which are currently > reserved/RAZ, and it will be rather painful to fix up accesses to this. > So we will not fix. This one fixes el1 only, and don't pretend for more. > Additionally, this workaround will silently mask other bugs in this area > (e.g. if registers like ID_AA64MMFR0_EL1 were to trap for some reason on > an implementation), which doesn't seem good. > We can mask it less silently, for example, print message to dmesg. Initially I was thinking about erratas as well, but Arnd suggested this approach, and now think it's better. From consumer point of view, it's much better to have a warning line in dmesg, instead of bricked device, after another kernel or driver update. > Thanks, > Mark. > > > Tested on QEMU emulator version 2.3.0 (Debian 1:2.3+dfsg-5ubuntu9.2) > > that does not implement SYS_ID_AA64MMFR2_EL1 register. (Fixed in new > > releases), > > > > Discussion: https://lkml.org/lkml/2016/3/29/931 > > > > Signed-off-by: Yury Norov > > --- > > arch/arm64/include/asm/cputype.h | 17 +++++++++++++++-- > > arch/arm64/include/asm/exttable.h | 21 +++++++++++++++++++++ > > arch/arm64/include/asm/uaccess.h | 15 --------------- > > arch/arm64/kernel/entry.S | 3 ++- > > arch/arm64/kernel/traps.c | 6 ++++++ > > arch/arm64/mm/extable.c | 2 +- > > 6 files changed, 45 insertions(+), 19 deletions(-) > > create mode 100644 arch/arm64/include/asm/exttable.h > > > > diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h > > index 87e1985..9660130 100644 > > --- a/arch/arm64/include/asm/cputype.h > > +++ b/arch/arm64/include/asm/cputype.h > > @@ -90,13 +90,26 @@ > > #ifndef __ASSEMBLY__ > > > > #include > > +#include > > > > -#define read_cpuid(reg) ({ \ > > +#define __read_cpuid(reg, err) ({ \ > > u64 __val; \ > > - asm("mrs_s %0, " __stringify(SYS_ ## reg) : "=r" (__val)); \ > > + asm ( \ > > + "1:mrs_s %0, " reg "\n" \ > > + "2:\n" \ > > + " .section .fixup, \"ax\"\n" \ > > + " .align 2\n" \ > > + "3: mov %w0, %1\n" \ > > + " b 2b\n" \ > > + " .previous\n" \ > > + _ASM_EXTABLE(1b, 3b) \ > > + : "=r" (__val) \ > > + : "i" (err)); \ > > __val; \ > > }) > > > > +#define read_cpuid(reg) __read_cpuid(__stringify(SYS_ ## reg), 0) > > + > > /* > > * The CPU ID never changes at run time, so we might as well tell the > > * compiler that it's constant. Use this function to read the CPU ID > > diff --git a/arch/arm64/include/asm/exttable.h b/arch/arm64/include/asm/exttable.h > > new file mode 100644 > > index 0000000..c0a66c8 > > --- /dev/null > > +++ b/arch/arm64/include/asm/exttable.h > > @@ -0,0 +1,21 @@ > > +#ifndef __ASM_EXTTABLE_H > > +#define __ASM_EXTTABLE_H > > + > > +#include > > + > > +#define ARCH_HAS_RELATIVE_EXTABLE > > + > > +#define _ASM_EXTABLE(from, to) \ > > + " .pushsection __ex_table, \"a\"\n" \ > > + " .align 3\n" \ > > + " .long (" #from " - .), (" #to " - .)\n" \ > > + " .popsection\n" > > + > > +struct exception_table_entry > > +{ > > + int insn, fixup; > > +}; > > + > > +extern int fixup_exception(struct pt_regs *regs); > > + > > +#endif /* __ASM_EXTTABLE_H */ > > diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h > > index 0685d74..19cfdc5 100644 > > --- a/arch/arm64/include/asm/uaccess.h > > +++ b/arch/arm64/include/asm/uaccess.h > > @@ -48,15 +48,6 @@ > > * on our cache or tlb entries. > > */ > > > > -struct exception_table_entry > > -{ > > - int insn, fixup; > > -}; > > - > > -#define ARCH_HAS_RELATIVE_EXTABLE > > - > > -extern int fixup_exception(struct pt_regs *regs); > > - > > #define KERNEL_DS (-1UL) > > #define get_ds() (KERNEL_DS) > > > > @@ -117,12 +108,6 @@ static inline void set_fs(mm_segment_t fs) > > #define access_ok(type, addr, size) __range_ok(addr, size) > > #define user_addr_max get_fs > > > > -#define _ASM_EXTABLE(from, to) \ > > - " .pushsection __ex_table, \"a\"\n" \ > > - " .align 3\n" \ > > - " .long (" #from " - .), (" #to " - .)\n" \ > > - " .popsection\n" > > - > > /* > > * The "__xxx" versions of the user access functions do not verify the address > > * space - it must have been done previously with a separate "access_ok()" > > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S > > index 1f7a145..6b88096 100644 > > --- a/arch/arm64/kernel/entry.S > > +++ b/arch/arm64/kernel/entry.S > > @@ -377,7 +377,8 @@ el1_undef: > > */ > > enable_dbg > > mov x0, sp > > - b do_undefinstr > > + bl do_undefinstr > > + kernel_exit 1 > > el1_dbg: > > /* > > * Debug exception handling > > diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c > > index cacd30a..515444a 100644 > > --- a/arch/arm64/kernel/traps.c > > +++ b/arch/arm64/kernel/traps.c > > @@ -386,6 +386,12 @@ asmlinkage void __exception do_undefinstr(struct pt_regs *regs) > > if (call_undef_hook(regs) == 0) > > return; > > > > + /* > > + * Are we prepared to handle this kernel fault? > > + */ > > + if (fixup_exception(regs)) > > + return; > > + > > if (unhandled_signal(current, SIGILL) && show_unhandled_signals_ratelimited()) { > > pr_info("%s[%d]: undefined instruction: pc=%p\n", > > current->comm, task_pid_nr(current), pc); > > diff --git a/arch/arm64/mm/extable.c b/arch/arm64/mm/extable.c > > index 81acd47..c140688 100644 > > --- a/arch/arm64/mm/extable.c > > +++ b/arch/arm64/mm/extable.c > > @@ -3,7 +3,7 @@ > > */ > > > > #include > > -#include > > +#include > > > > int fixup_exception(struct pt_regs *regs) > > { > > -- > > 2.5.0 > > > > > > _______________________________________________ > > linux-arm-kernel mailing list > > linux-arm-kernel@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > >