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 88761C3DA4A for ; Sat, 10 Aug 2024 03:21:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 849306B008A; Fri, 9 Aug 2024 23:21:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7F8836B0092; Fri, 9 Aug 2024 23:21:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C0CC6B0095; Fri, 9 Aug 2024 23:21:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 4F3436B008A for ; Fri, 9 Aug 2024 23:21:15 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D1314C1729 for ; Sat, 10 Aug 2024 03:21:14 +0000 (UTC) X-FDA: 82434884868.16.1C11F36 Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by imf24.hostedemail.com (Postfix) with ESMTP id 6A600180013 for ; Sat, 10 Aug 2024 03:21:12 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=dmJVjwxS; spf=pass (imf24.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=1723260039; a=rsa-sha256; cv=none; b=dRwdZWvUq4Nxf5wJ4RFlY+1fKmbsIAFoEckByJOVYFad6Mqd5dgaH6DaVVd999v5m+0J5m AklnCLiw68DbjPvtzn+izW9HZWJmazMPxTMBOdhdVJ4UiGVqThH9V0CELa9KC1+7+9eVs3 hXZitvgs9phF1JhJ7WTdo5npm1sMl+A= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=dmJVjwxS; spf=pass (imf24.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=1723260039; 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=EWj1ieL4VaFASgQnFt9FPnrOKju2ddoBf6+jL+AxRwQ=; b=ki5TqkGUJCWc/p5Ly6jBaXBJae8z7Yq3dwMlQo0cAYo+CHzem/rRljSBoyhvahu9bFAEsI /M9YDt0xndyLlVyVUvoOzuH9eRXxf51aFkoSWFXmCJ7BYzuBIBVr7UtgUgMt1uTImXSic5 6bhxt9joy0cLl48AdR3r6e3xWwBzrjs= Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id CA29540E0263; Sat, 10 Aug 2024 03:21:09 +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 aChhZq3rybOW; Sat, 10 Aug 2024 03:21:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1723260060; bh=EWj1ieL4VaFASgQnFt9FPnrOKju2ddoBf6+jL+AxRwQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dmJVjwxSb3wPTXSvs3oXps257Op2uZQlX4caBfXvS2vAeXkxXaGQiRkonq9s6yMvc QTgova5d440avYtiec6QtrOsPmtgQ7+BmSbwGM9JHDzKiLYpVd2eWJcIKYg7BFS51C nNrVlr6dNF6N2YW4JDPFFfF4KSlTsOGgVwfYNwywB+COl7NiB3NTIjUFpnZqxTq5k3 wi17hrMHIugA+sLSbkB7aB/L19T4W9YKaiL8oUjl6Vq0DM5jpaDdSPXet/0s518x5B QoyciqxkPOZXn6fn37CiIMerRX/J4ZHY+vHNJFuk44EFvyW1COUr8YeTDGFaO9onfv 7gBxs6RP3zBJXPdSNSYppLFULrBOf+hyJBd69aYKvQkM2qNXVIf8yagh45FuG3aP9X pEOh/uvUcrTiqqD5oZiwMJsA6eR9wdLKJ3/8a4YyZvRUcJT9JEbqQ6CG1eVdWAbmb5 AWU5OyOTetuty0RTShq1o3KGBKlgBqZ5FAtSTyKr8LV5f/ESeV8NYLSjE/x4K8MKwj nCinz+0DDSFsmtlT8S41T3oD4Bh7AuGTVUppl0C6qva6+XwToivnCzVxzhcbrEsRv1 VcvnyCONYPecnQfp30QQNVWpdPGlOVDcua7UiBUdQMf/DmEGpeZ7pMEJEL8Gy9lvWJ aI4AkFlbY0rjihVcfBKBYZto= Received: from nazgul.tnic (unknown [87.120.165.225]) (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 493EE40E022F; Sat, 10 Aug 2024 03:20:53 +0000 (UTC) Date: Sat, 10 Aug 2024 05:21:49 +0200 From: Borislav Petkov To: Andrew Zaborowski Cc: "linux-edac@vger.kernel.org" , "linux-mm@kvack.org" , Eric Biederman , "x86@kernel.org" , Tony , Andrew Zaborowski Subject: Re: [RESEND][PATCH 1/3] x86: Add task_struct flag to force SIGBUS on MCE Message-ID: <20240810032134.GAZrbcvpn_cYzFdEwB@fat_crate.local> References: <20240723144752.1478226-1-andrew.zaborowski@intel.com> <202408052135.342F9455@keescook> <6273D749-9CEC-45E4-8C56-FA3A1DBE1137@alien8.de> <20240808145331.GAZrTb60FX_I3p0Ukx@fat_crate.local> <20240809083229.GAZrXUHfjgVcHSZPsb@fat_crate.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Stat-Signature: bsr4o3p7ntrat6ru5d6tjoxfxopsn8ud X-Rspamd-Queue-Id: 6A600180013 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1723260072-447795 X-HE-Meta: U2FsdGVkX1/Mv18VW9nId2kd80fh2p60C2sAT3lW/YgUi+d3Sz9U0+PPqWhM0ekVOEfOTPxldlnRwQSCVKKdC+B2k0owlknI3/EM/je2TJ83eLPvot5IqUQB6qSGoj0WliLlVb5a0TK2/q5oHUXJRkF9uPaEhoU2EuVARF6tnDFomjCIleFA6Q5ccgoKc3Yapl3k7EItFFmWacgiyANPlrUm2jasKvbe6/Ifeygr0h0Y05ZMXkuylaxLD4iZuwb/ZOdKgzjF1vkTW0agaaVAfz8ll8Uf8EL7lsOye0dxS6OJkTRQKT+klKXpeDGHTLDckTYhDfEXGrtoR5QMd0CvRCDrelTd7x48zQkSAD7osyti6KtfVmiGOrYQYe5WW35iSUpL9KT4uqmPv0iXBnkXxzWtGluWqM1FzVgstGeKmZjYYbNU4KQWSzGyYFv4W6Ee89nB28VVVmtit6TV+aKh7BXf/+8+FUF6HPWjhfxbHeSZyFICLDg8Q+0iPTRFdHnkSZ6XSzxA/zL/qbs2AalPZwkNIJ7jebqZdBxoLTfocA6ybeBSCVJt9KSmWvMdNHTW7frNrmpMKEw1iv8aYBScGYSKU6YPUFSTZ/OtK9ReKmT2eCJH/F/VYOG2R2359DjxMIPmSXmsTiY+fUqN3VeVY4GTE/XAmO0GZziC0GhJ4Pcw0T/Nn3UanhnEOfUxT3kHmSBxlf8KEalqzU4jbNGh4p3wJ8mJ0VWU+mAzAZ/qltJYGdCKOIWmpU/DyJ9f6TEJQ1mG7shOd1kT3oKTUaYmOXlYC0vT6ptkswa59DrjX5ftTzxbVZGHUqvZ+Wdj9a7lqemmb0qnppQgNSO2WvZqbUYVhLZBFj+EYmg7M8CocSMRrrljiFYblVNSpgboofggU5IfLdT0ONtSUDu0WB25BIMYgo03V6uw7JCoNV1klano74JnuMtM9JhzlL/MnBtZ7kfXjNzyQp3N3N+dob/ dCQY34aV WZJ1mNfI9ydLdDWIOOWvTo+CyaRf3RSESYxKsl2oGOszCvE9sDXrvU7COF3nOXfpeR9w35c6knaKbLXxqFfRv6KTDiQ5DnvtH5xVrg8nDJBxk8mH5nDojrJTm94j5XgBEvxK8wckKlvUibQ2SCg6NvdvSO0AEuDSDGuNCp4kaEfcyvIKjj0vrAM1E92pW3IJgB4BxNp+IC/7Y/KZ7w75NNtqJBj/Ym8dGiE+7e1uzGNMyI9rkJ1wdSXFJw3rTnssXBCVFodoTAXbH3/bFW5805705cCB8ftLqtYX/lgDN01u92VHUGNXNPaHosb1OvN3b3lSc X-Bogosity: Ham, tests=bogofilter, spamicity=0.000140, 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 Sat, Aug 10, 2024 at 03:20:10AM +0200, Andrew Zaborowski wrote: > True, though that's hard to link to a specific process crash. The process name when the MCE gets reported is *actually* there in the splat: current->comm. > I was replying to your comment about the size of the change. My comment was about the code you're adding: arch/x86/kernel/cpu/mce/core.c | 18 +++++++++++++++++- fs/exec.c | 15 ++++++++++++--- include/linux/sched.h | 2 ++ kernel/rseq.c | 25 +++++++++++++++++++++---- 4 files changed, 52 insertions(+), 8 deletions(-) If it is in drivers, I don't care. But it is in main paths and for a questionable use case. > Supporting something generally includes supporting the common and the > obscure cases. Bullshit. We certainly won't support some obscure use cases just because. > From the user's point of view the kernel has been committed to > supporting these scenarios indefinitely or until the deprecation of > the SIGBUS-on-memory-error logic, and simply has a bug. And lemme repeat my question: So why does it matter if a process which is being executed and gets an MCE beyond the point of no return absolutely needs to return SIGBUS vs it getting killed and you still get an MCE logged on the machine, in either case? Bug which is seen by whom or what? If a process dies, it dies. > In these tests the workload was simply relaunched on a SIGBUS which > sounded fair to me. A qemu VM could similarly be restarted on an > unrecoverable MCE in a page that doesn't belong to the VM but to qemu > itself. If an MCE hits at that particular point once in a blue moon, I don't care. If it is a special use case where you inject an MCE right then and there to test recovery actions, then that's perhaps a different story. Usually, a lot of things can be done. As long as there's a valid use case to support. But since you hesitate to explain what exactly we're supporting, I can't help you. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette