From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 050BAC4167B for ; Thu, 30 Nov 2023 17:43:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 959726B042D; Thu, 30 Nov 2023 12:43:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 909486B042E; Thu, 30 Nov 2023 12:43:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 81F7F6B042F; Thu, 30 Nov 2023 12:43:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 726EB6B042D for ; Thu, 30 Nov 2023 12:43:51 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 524AB1C02B7 for ; Thu, 30 Nov 2023 17:43:51 +0000 (UTC) X-FDA: 81515343462.05.4902A9E Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf30.hostedemail.com (Postfix) with ESMTP id 7B76280012 for ; Thu, 30 Nov 2023 17:43:49 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf30.hostedemail.com: domain of james.morse@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=james.morse@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701366229; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=n6E/KMc6fd9ywjkDP7JwJ3J0cfBwqIcTtB0EmKsxv68=; b=Cm4xNnGexEK+x2rng4obQWBjKTnjFW9a2YhOUw7+BeUnOHn1lhlTyDlEZipzNWq8EsvWrM 9X49OOHCRRzI7NIW9r2BhH1Zm5IsV8lOvvjXX7g2zXnpr0C+oMj2gM695J2RTh89+e+ZMa 23uYP8xRam7EqTw1bVTKcWPpmFvpPk8= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf30.hostedemail.com: domain of james.morse@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=james.morse@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701366229; a=rsa-sha256; cv=none; b=14m+iX9I8/T3Zonr9rFjADZqUVHCT1sMhJWzAXgkej/sNNT+LT5YREDk5lkdR2ctWZwOAv YM+eSSVz4Y6aagNojpMEIzwLIyDvTNQdsiSbp5hLY7jsx2qUl5EJ04ESvoS6N/pRwXI7AR 96gM9a+cNabw6O382EH0NYyqGqIRiC0= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3E42F1756; Thu, 30 Nov 2023 09:44:35 -0800 (PST) Received: from [10.1.197.60] (eglon.cambridge.arm.com [10.1.197.60]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B012C3F6C4; Thu, 30 Nov 2023 09:43:44 -0800 (PST) Message-ID: Date: Thu, 30 Nov 2023 17:43:38 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH v9 0/2] ACPI: APEI: handle synchronous errors in task work with proper si_code Content-Language: en-GB To: Borislav Petkov , Shuai Xue Cc: rafael@kernel.org, wangkefeng.wang@huawei.com, tanxiaofei@huawei.com, mawupeng1@huawei.com, tony.luck@intel.com, linmiaohe@huawei.com, naoya.horiguchi@nec.com, gregkh@linuxfoundation.org, will@kernel.org, jarkko@kernel.org, linux-acpi@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, linux-edac@vger.kernel.org, acpica-devel@lists.linuxfoundation.org, stable@vger.kernel.org, x86@kernel.org, justin.he@arm.com, ardb@kernel.org, ying.huang@intel.com, ashish.kalra@amd.com, baolin.wang@linux.alibaba.com, tglx@linutronix.de, mingo@redhat.com, dave.hansen@linux.intel.com, lenb@kernel.org, hpa@zytor.com, robert.moore@intel.com, lvying6@huawei.com, xiexiuqi@huawei.com, zhuo.song@linux.alibaba.com References: <20221027042445.60108-1-xueshuai@linux.alibaba.com> <20231007072818.58951-1-xueshuai@linux.alibaba.com> <20231123150710.GEZV9qnkWMBWrggGc1@fat_crate.local> <9e92e600-86a4-4456-9de4-b597854b107c@linux.alibaba.com> <20231125121059.GAZWHkU27odMLns7TZ@fat_crate.local> <1048123e-b608-4db1-8d5f-456dd113d06f@linux.alibaba.com> <20231129185406.GBZWeIzqwgRQe7XDo/@fat_crate.local> <20231130144001.GGZWiewYtvMSJir62f@fat_crate.local> From: James Morse In-Reply-To: <20231130144001.GGZWiewYtvMSJir62f@fat_crate.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Stat-Signature: 6ot5hhapz8ufwc1jptco1mcdtakn87bg X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 7B76280012 X-HE-Tag: 1701366229-655480 X-HE-Meta: U2FsdGVkX1/rjsqFo9x+nSDM10zOyazGPpgalyJLrvxgHDR4arshrs+TNfNTND6Til0L6Qnt5hpNJF4Ho64muBCwW2TXyJJN49Pg2qyEgLIKWi1qlxiwP9v49ZuRI0bhYtWu3XYmF3PJkawpPSy+jeWAANqYeWdi3gKHX1iYaeHyDHR7hFEgnkHhnJIjMiSVMAXH6Wb3wcbR0q0LWgv06fcRU8gJVBfpDPJjCpFKOFEX2AAgnkwDBeuMln2eWjOkROaY6p9u9z0j9vnLMUaUveZ55nIZpj1ci4JAqxcO+mOucirbFAkxnBpCkv4FTS4AKbNoTc/7uUqZxEunt5wj/LKrsugekQqEMsnToSM8Ba2QCW0z/u0XmPv6Yx4FNcQgF+4Rpdf6blX85rKhnlOXzDyJNpAqd4kBTC51Gn2uMnMCDyduRQAEx446fFxqbdVW3ur6y/J9r5qRggkrnO3F3q/s23hDxlyDfZhxC2wituzPCN87e9Rq18eT9yFNryRNYWApLfiCZq4wTfI2IapB1VTa2eyUUQCmWPUWAE9F//B4+hWPfu0S8sN45/bgWPg1GSZEuTAL88BXiECdylg/4Qu23lJ6/vUF/WqHCihy19VjkKfhKwxumPEtewPM2qP2uamuTPmYhS/qfOIwh2eJdVrXm2cZkcCrXR1F4uDINExeU4vdLY07qvHLXeWzEq5nUyCsymQJzFlAPApNsGJjD/soj3xnohtUOrodOvfXKDzM/Yp8fgNX9cLfCPpdumCIDg3DCN5/c8m5UVl62zmEUqWpoFbHEY+7K8gahfxxI8B+X+7VvcMtFrBaXqMdI5rPn9LJTSEgXuJnXqbPbfLw+F3cmKqPRXNI+8pvJRU4tNVjkoaW0fvICtCsJkosvjQbIYcaRQHKWpO5D+li/6pPipcEX+0AspvkAwzVBV4tIoTgZOGlGX9BVDT7fQv6aNS9EnZiAhwGOUnGPBJFOWz v99qFHK3 6QtGW5IjfTIP505JlurWf7Sf1mfuk+zUPNDSZEnqMIgtEjhO1xhayfpklT2yC6FH5inEGGt0qN/rkcgbJirM98CYOK6WjfLIqeDv1IRuQ8NkLtNp0cCn3Ciez4bKDuStyO13OEYeQP4N4qgO9lxTIMrnIVVG767odFxr+ X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi Boris, On 30/11/2023 14:40, Borislav Petkov wrote: > FTR, this is starting to make sense, thanks for explaining. > > Replying only to this one for now: > > On Thu, Nov 30, 2023 at 10:58:53AM +0800, Shuai Xue wrote: >> To reproduce this problem: >> >> # STEP1: enable early kill mode >> #sysctl -w vm.memory_failure_early_kill=1 >> vm.memory_failure_early_kill = 1 >> >> # STEP2: inject an UCE error and consume it to trigger a synchronous error > > So this is for ARM folks to deal with, BUT: > > A consumed uncorrectable error on x86 means panic. On some hw like on > AMD, that error doesn't even get seen by the OS but the hw does > something called syncflood to prevent further error propagation. So > there's no any action required - the hw does that. > > But I'd like to hear from ARM folks whether consuming an uncorrectable > error even lets software run. Dunno. I think we mean different things by 'consume' here. I'd assume Shuai's test is poisoning a cache-line. When the CPU tries to access that cache-line it will get an 'external abort' signal back from the memory system. Shuai - is this what you mean by 'consume' - the CPU received external abort from the poisoned cache line? It's then up to the CPU whether it can put the world back in order to take this as synchronous-external-abort or asynchronous-external-abort, which for arm64 are two different interrupt/exception types. The synchronous exceptions can't be masked, but the asynchronous one can. If by the time the asynchronous-external-abort interrupt/exception has been unmasked, the CPU has used the poisoned value in some calculation (which is what we usually mean by consume) which has resulted in a memory access - it will report the error as 'uncontained' because the error has been silently propagated. APEI should always report those a 'fatal', and there is little point getting the OS involved at this point. Also in this category are things like 'tag ram corruption', where you can no longer trust anything about memory. Everything in this thread is about synchronous errors where this can't happen. The CPU stops and does takes an interrupt/exception instead. Thanks, James