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 3EA27C021B6 for ; Mon, 24 Feb 2025 22:02:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C5ED5280015; Mon, 24 Feb 2025 17:02:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C0D6328000D; Mon, 24 Feb 2025 17:02:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A8734280015; Mon, 24 Feb 2025 17:02:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 86D3B28000D for ; Mon, 24 Feb 2025 17:02:18 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 417391A026D for ; Mon, 24 Feb 2025 22:02:18 +0000 (UTC) X-FDA: 83156212356.08.E82E32F Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by imf07.hostedemail.com (Postfix) with ESMTP id 2E9884000E for ; Mon, 24 Feb 2025 22:02:15 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=FWpxCUm7; spf=pass (imf07.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740434536; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ZBR+ADqnnnM3sXp77K9ZzJ39W0vxRbheejoHC6DUJTs=; b=8NiUqiHTer5rX9RBkUbEjnCl8hzNxu8d+FiVLhWdLy2ni4OPCsHTELndRBJAQHbJv+7KR4 jL+L0U4N3n1lC4rjCnHlOmTgrq0AaCpDt8s3uvBM/ExyB4SAQuszDxAC1kVTBGWCJ4RjUe f5WFQtE83VDMLz877awbVq4IeyXsEjg= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=FWpxCUm7; spf=pass (imf07.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740434536; a=rsa-sha256; cv=none; b=gVrBS6/sfZegx40e3Lhs4hFEJ+dwliu+zOdn6TjYA6cKGPUxDWmyILX7kSrSUhFEVjnQxO J3350tu7RrvEwGYb0G1UAvV5aUzPWDoQji4I11N/4ocSyFHjhBEAUgDJ7R2ysU62+11/zw Y3o/hZl+KMcZOGQsitfFlHKKVcz5XmQ= Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 16F6E40E01AD; Mon, 24 Feb 2025 22:02:13 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id dasogVygUtBK; Mon, 24 Feb 2025 22:02:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1740434529; bh=ZBR+ADqnnnM3sXp77K9ZzJ39W0vxRbheejoHC6DUJTs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FWpxCUm7L7h99WwLCtPh++7b0CVG2n05Rklf8+bCimGPwpYUdTbVyACoenHRwI1An kAizWc+ZVoNFQpU3MJ71COJdWj0d1zU6BD7NCQ5d9h9q62o+PPHQ90ln9L7e+JDIn1 2oCP9LZsLOUS17wai/mVhefPp5ERd8uPylL7T2B260kglWP4ZAGVd+EOUcKYJoYTBr bO1F/+pHuc8N8ra/QP53WcF2g5PUsqIX8pcFKOPLciIT/IJnilZ1+ehXoz+CYLodES t817GlpTK5J/bRJZA4OvVhFEl7WTZiRywDOz6GuY7fAN+3vPGaST1BcYulGjLzYD+c QNCD5n7asyFH612IJkLmigZUmjffWEMIFNuQaql8Qw8YC8Bu0V0iJpNRVRkrQZ3Rha eso/7QTqLZ95fYHA7ubaCX5Iq8xfSqe5h/jGNhf33ergcpyIkv1no+9xy5PLwrW3PX +jXwynO08uDvRCildtfgzmmblnccQZyo+NIpAnoJ6DCOxaFLeiklmO0Kf4ax9T+p0G tEm5WSONSwr2/EoGmt4lJB4FU/FwvaEmZavGURaVUvJY28ZGkT8FBQjFswAEi8KO+s Je59+cg8L+n7O1LLzL+Owv8FeyUckMPj1unnMuXz0GK1umUvHeuqJIn5Rhl1QhPeGs 9VL0/jANcrrNvcmFyFaj/Adg= Received: from zn.tnic (pd95303ce.dip0.t-ipconnect.de [217.83.3.206]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id D8B8F40E0184; Mon, 24 Feb 2025 22:01:51 +0000 (UTC) Date: Mon, 24 Feb 2025 23:01:46 +0100 From: Borislav Petkov To: Shuai Xue Cc: "Luck, Tony" , "nao.horiguchi@gmail.com" , "tglx@linutronix.de" , "mingo@redhat.com" , "dave.hansen@linux.intel.com" , "x86@kernel.org" , "hpa@zytor.com" , "linmiaohe@huawei.com" , "akpm@linux-foundation.org" , "peterz@infradead.org" , "jpoimboe@kernel.org" , "linux-edac@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "baolin.wang@linux.alibaba.com" , "tianruidong@linux.alibaba.com" Subject: Re: [PATCH v2 0/5] mm/hwpoison: Fix regressions in memory failure handling Message-ID: <20250224220146.GBZ7zsSnXLftyqWzW_@fat_crate.local> References: <20250217063335.22257-1-xueshuai@linux.alibaba.com> <20250218082727.GCZ7REb7OG6NTAY-V-@fat_crate.local> <7393bcfb-fe94-4967-b664-f32da19ae5f9@linux.alibaba.com> <20250218122417.GHZ7R78fPm32jKYUlx@fat_crate.local> <20250219081037.GAZ7WR_YmRtRvN_LKA@fat_crate.local> <20250220111903.GDZ7cPp1qVq3t9Jgs6@fat_crate.local> <4e13bef2-7402-4f75-8f0c-4a3cc210c5a6@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4e13bef2-7402-4f75-8f0c-4a3cc210c5a6@linux.alibaba.com> X-Rspam-User: X-Stat-Signature: yt633cbfn43cpapu31eutsuxmi8n5df6 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 2E9884000E X-HE-Tag: 1740434535-314034 X-HE-Meta: U2FsdGVkX18xaeQIvytnVpCKYkj2ETFfIJ4kUdYAeH5tNrmy1MvsxOe5IJJuDclhRvyz29ntoS9ST3VfJ9r/+iohWcrCYoQPjUHe4mj9BJV6ljdG2fGKCSww45dvM4tvpFIB2fzRN3q12s1kH3izRUx/Or9OQ7IGhtlKM7Y5Gi0c6lVH57r+8RkwkfGTxBjeqd574aEFdZgufDF3M2jhe6IVQlARptXQunUQI567HjQ38Px9bkGhwv/3AXOcgIqdWLPEeHvKSP1vyn6a6HK94PHH8dTEuz7GcA/nZddWYK8qc2E5Jnb43rgUhUiLjv4u+6PdeeVwr1mImWcSBaZ5x1szBOw0YQmP51iYyE908gVR/8fOP9JUdezWHexP6PfZAL8GqVllJuJ066DeSD4lUEKAnDYHKPCGkuJiR7UWLjU/Hjhd2lEuGufB6mUWWwghe2BmuBYn7pJTMjaHzEj3mxiKWsIk0qRRNPUv4E3wr2Syj5kUcM3O+2u/+sxcpXR+GIP7zrg+rv5qGr7tI+ZNMrpnPY6tXy68jU7H1eQOgPeT/RawmRPYLSe7RyhWWc15uLKAxPyZxt2MJa/xlqJqxHq+TlnWteiK8mmI5URnHJu/HOxzD7rl1Qm3xPVw8YALQwv4DcaEPpggi5Xi0FaAeThq95hqB7cWU6Jr5zDmJLkpxPt2L4NjtTUDHWH0uQW8LHn8IWROaeO32mLab8PO/bRIYKvkYHgkV3oGFAXg/0dOiAcJnTdk4M9vDUhJqfBIWjwQ5FOQCWnpgapfQMq18DoIoP+4NdrItlF0OC7HlAaP9MkgPaUDfx1BZTCiGA8diCwvP9QXlpMPzGUtnRjbDR8SI+BRwFU4ZIUv7YbkzqRGNDxNqWdHgeUKZDgEVbVMPdV4IcOL4PBvb1V+K0eRXYK7DS6U4qy+rVmFWEeDjVA/c0NG+Zl8KPlF+2MeHzV88DovyHROEOSrGRJY/Xf MCu/DU4H TYfqyi/FWEK9u4r5v3r49ZNeJQQeXOk+aN0ISRRNei9qK2t4z1WCQajRWFiSElCOR5nAHhLnXTlj0jAmhJYbk4et/JRG8tgDdfHz9IgcYzqVGg8FAwg0lPSjiQJWk5L+hIJvOAn8Z64k7iUwsWF66buHkZKU8r/29DLp36G+yEhQhm8f5mEgM+lDQ3yJ7i4z6al5P8myRklSzRGFbbrIfuFUW/XVDtf8hLXy+x2qyTjeKn1choUewB7vYrLxIAPLJ8ak5ToaeWCW6LWzoASMHsQOvP/X9wVgvqo46osshu5whsBk9jlGI0tSVoXua6ppA2uvD0fQ4erKzltmtidl9O4xdQMVPST5ejFHyCKOs/63LptUQqXDVHeNrYtL0UbccXpNl X-Bogosity: Ham, tests=bogofilter, spamicity=0.054668, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Feb 21, 2025 at 02:05:28PM +0800, Shuai Xue wrote: > #perf script > kworker/48:1-mm 25516 [048] 1713.893549: probe:memory_failure: (ffffffffaa622db4) > ffffffffaa622db5 memory_failure+0x5 ([kernel.kallsyms]) > ffffffffaa25aa93 uc_decode_notifier+0x73 ([kernel.kallsyms]) > ffffffffaa3068bb notifier_call_chain+0x5b ([kernel.kallsyms]) > ffffffffaa306ae1 blocking_notifier_call_chain+0x41 ([kernel.kallsyms]) > ffffffffaa25bbfe mce_gen_pool_process+0x3e ([kernel.kallsyms]) > ffffffffaa2f455f process_one_work+0x19f ([kernel.kallsyms]) > ffffffffaa2f509c worker_thread+0x20c ([kernel.kallsyms]) > ffffffffaa2fec89 kthread+0xd9 ([kernel.kallsyms]) > ffffffffaa245131 ret_from_fork+0x31 ([kernel.kallsyms]) > ffffffffaa2076ca ret_from_fork_asm+0x1a ([kernel.kallsyms]) > > einj_mem_uc 44530 [184] 1713.908089: probe:memory_failure: (ffffffffaa622db4) > ffffffffaa622db5 memory_failure+0x5 ([kernel.kallsyms]) > ffffffffaa2594fb kill_me_maybe+0x5b ([kernel.kallsyms]) > ffffffffaa2fac29 task_work_run+0x59 ([kernel.kallsyms]) > ffffffffaaf52347 irqentry_exit_to_user_mode+0x1c7 ([kernel.kallsyms]) > ffffffffaaf50bce noist_exc_machine_check+0x3e ([kernel.kallsyms]) > ffffffffaa001303 asm_exc_machine_check+0x33 ([kernel.kallsyms]) > 405046 thread+0xe (/home/shawn.xs/ras-tools/einj_mem_uc) > > einj_mem_uc 44531 [089] 1713.916319: probe:memory_failure: (ffffffffaa622db4) > ffffffffaa622db5 memory_failure+0x5 ([kernel.kallsyms]) > ffffffffaa2594fb kill_me_maybe+0x5b ([kernel.kallsyms]) > ffffffffaa2fac29 task_work_run+0x59 ([kernel.kallsyms]) > ffffffffaaf52347 irqentry_exit_to_user_mode+0x1c7 ([kernel.kallsyms]) > ffffffffaaf50bce noist_exc_machine_check+0x3e ([kernel.kallsyms]) > ffffffffaa001303 asm_exc_machine_check+0x33 ([kernel.kallsyms]) > 405046 thread+0xe (/home/shawn.xs/ras-tools/einj_mem_uc) What are those stack traces supposed to say? Two processes are injecting, cause a #MC and a kworker gets to handle the UC? All injecting to the same page? What's the upper limit on CPUs seeing the same hw error and all raising a CMCI/#MC? > - kill_accessing_process() is only called when the flags are set to > MF_ACTION_REQUIRED, which means it is in the MCE path. > - Whether the page is clean determines the behavior of try_to_unmap. For a > dirty page, try_to_unmap uses TTU_HWPOISON to unmap the PTE and convert the > PTE entry to a swap entry. For a clean page, try_to_unmap uses ~TTU_HWPOISON > and simply unmaps the PTE. > - When does walk_page_range() with hwpoison_walk_ops return 1? > 1. If the poison page still exists, we should of course kill the current > process. > 2. If the poison page does not exist, but is_hwpoison_entry is true, meaning > it is a dirty page, we should also kill the current process, too. > 3. Otherwise, it returns 0, which means the page is clean. I think you're too deep into detail. What I'd do is step back, think what would be the *proper* recovery action and then make sure memory_failure does that. If it doesn't - fix it to do so. So, what should really happen wrt recovery action if any number of CPUs see the same memory error? -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette