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 88E70C3DA7F for ; Sat, 10 Aug 2024 03:56:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CAD306B007B; Fri, 9 Aug 2024 23:55:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C5CCF6B008A; Fri, 9 Aug 2024 23:55:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AD68A6B0092; Fri, 9 Aug 2024 23:55:59 -0400 (EDT) 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 8A1746B007B for ; Fri, 9 Aug 2024 23:55:59 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 007DDA170D for ; Sat, 10 Aug 2024 03:55:58 +0000 (UTC) X-FDA: 82434972396.23.947A9BA Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by imf15.hostedemail.com (Postfix) with ESMTP id B9ECFA0013 for ; Sat, 10 Aug 2024 03:55:56 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=none; spf=pass (imf15.hostedemail.com: domain of balrogg@gmail.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=balrogg@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=intel.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723262090; 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; bh=sRu4U78Liz7L9GrLLIkOrIFgbDpdS/BRBdY91q3MGdM=; b=umln0jlAIHogxCjGpbjmUfpgNurDtEHJOR1QOuTrXpohPI4mwH6nn2mwZdQTYBhBlohDo9 5qngxG7Iv/scxN/spo3uXVHJVXHdb7QQoA5+8dCTJuVlHWbzKxxw7DqWkDMSaNn2++1zGr c80BTX3OOvKPFiG/YuwnZf8x3s8zDJY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723262090; a=rsa-sha256; cv=none; b=UNtBiLI8k+Kcc2a9rStJdJLlcF1HMBi6+y4xeTdaUB09C8E8BVv/fxSnewt+64D3c1H7hD Mf7KBQtuGovWcsVozFH7YXUQRz4kofpZncRah7Lbes85fvUZ1mC3SU5vOZi3bNyyy70vuN FswEbxTNiEDQDwJczZOEed8FjqWvno8= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=none; spf=pass (imf15.hostedemail.com: domain of balrogg@gmail.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=balrogg@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=intel.com (policy=none) Received: by mail-lf1-f48.google.com with SMTP id 2adb3069b0e04-52efd530a4eso3588920e87.0 for ; Fri, 09 Aug 2024 20:55:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723262154; x=1723866954; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=sRu4U78Liz7L9GrLLIkOrIFgbDpdS/BRBdY91q3MGdM=; b=rLSxmLaiX2PJb/TDF8uxE+Ypxw0cqPF7Wp6FPsCGksQTVb7F6TMhBLfa+z0IKvDMg2 mvoDf1BE/Ke9TA+exo2tZ5fJB+SZyoyYyCOCzscur3xxYg69Ebc8c+Z3Is+Cl6guNclj JuTJ1xFVlI+BiabonPMSqd8NHRY4imUgIVJCoThJJTknZjDY3saKnmQGR8JmuaNi7C0E /6R1hJeVa/OTUj6eTfUjSfraeWMh61OsEWoUm0s6CRcrhID+Y6gYZLhYQThkezqrx5jq p5hXQtw5wHrhT4+CzZsP9J6JwsZyA+/crZkMUiID2aDCVQhGu6NGTV7HRhUp1bm3KrNX JxaA== X-Forwarded-Encrypted: i=1; AJvYcCVPqglD6nbqvx32M9AephxMb6hcPYyfijIvzQ1cTdZOiabyeIDIqSC4SR6gfCUzvikESFSKFaOMJ+ezOg/r0xA3bpQ= X-Gm-Message-State: AOJu0Yzzl/940WqjZOMqOsm6tdKttOl6OEQ5bs1zHD01N27vkORvmKuK r0noG+Am3P6+jBAiwaodaJL7/5dR/ircOiM9Jpa28RVaVruGwMX5EbbU6gJcDjY= X-Google-Smtp-Source: AGHT+IGF1oNYlEhdRbHbYr13kPLUVJ4Sa72T/DfAgMFWrXd/tFpkcfUN42OZASs8GNyRyQHhzmXB3A== X-Received: by 2002:a05:6512:4015:b0:530:dab8:7dd8 with SMTP id 2adb3069b0e04-530ee992bfcmr2638611e87.9.1723262153920; Fri, 09 Aug 2024 20:55:53 -0700 (PDT) Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com. [209.85.208.176]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-53200eb3d34sm109083e87.18.2024.08.09.20.55.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Aug 2024 20:55:53 -0700 (PDT) Received: by mail-lj1-f176.google.com with SMTP id 38308e7fff4ca-2f136e23229so28304641fa.1 for ; Fri, 09 Aug 2024 20:55:53 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCXXZbMrWPUp0lNKjD6t1IBQ1BbzO6lFWiEzoKOBtaTOEN/uATtPDhKVUNJocsDZoJgMZTc3paz9klcykd/tjHJdQW8= X-Received: by 2002:a05:651c:79e:b0:2ef:26f2:d3e6 with SMTP id 38308e7fff4ca-2f1a6d59e8cmr21086211fa.34.1723262152892; Fri, 09 Aug 2024 20:55:52 -0700 (PDT) MIME-Version: 1.0 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> <20240810032134.GAZrbcvpn_cYzFdEwB@fat_crate.local> In-Reply-To: <20240810032134.GAZrbcvpn_cYzFdEwB@fat_crate.local> From: Andrew Zaborowski Date: Sat, 10 Aug 2024 05:55:41 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RESEND][PATCH 1/3] x86: Add task_struct flag to force SIGBUS on MCE To: Borislav Petkov Cc: "linux-edac@vger.kernel.org" , "linux-mm@kvack.org" , Eric Biederman , "x86@kernel.org" , Tony Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: B9ECFA0013 X-Stat-Signature: x16kxd1kr9p89ykauxoridxkmyam8wat X-HE-Tag: 1723262156-633345 X-HE-Meta: U2FsdGVkX1+Ee/m87Odb1SdMrLhXAI978VrPNcpU+aFB4m5QFaGNCXyRL0xcy/xRULmPn3H8DaSFnpd5tMbzOpoIMMkFZuRH03bEqrH2zWvBFU8Ak8xDH94z0jU3kK7N1LT1AxPfetWHeCgp6zhn+VR2sl0Eltg8zSDFoS4A2dObWnoXkw1fOFbFEvTQ2va6U+8Q40wux71CIW0rELfZ5+Sn2YGv7PZY4ev3GUdBfcQxDqZfGSPlTj19ePrVsihB3MzlGrkcEzMWSBcFr2MnJ3G5U4qsKjdF/81hk3Nc62e2qSyWKsRnC/QHLdyC3oj52xEleAR9jcnYGiWEorkb0jvGHoxGLYKiNLqut+zp0QKSm1yu25wPuRpljMOlcTL1+RspmrZRsKJeXlIRndOvUcFjX7s3KYcsAv+sjFGN/D7goia508C/Fx9rajdRpeeFO5JHTfFR6aTjMu9ivpXbmAAbPNUG4qeYvFltjwh7Ssu9VL4cYf3ucI6955fXA/qwJQAn02KHumRv+li9o1nUYft4lg7Bvt89EYIvtqI4MzMvLjbp10OWSW4D3cmheiwQApjOSPx6CpZPgwwzRv31Or+RqSqO76zuGF/onzX7O1fTWtiLr9bMAn71TJi9EoG88R7uGFbAxebSZbltNZj8h6zfJvAUNCQWTKtfKFWhSV+XMSm2vIg4X70aZdSJoPjFG0hEK92Y9vf6nlKyp+7kmNMPCJVJIAZNxF4Vjdy87wK9Qd0ypEFS55Q9zI//xh8flrBnZSFNSvT29EP/vYstjGzv/Xo0m0gF0sq+BjW0IEY9wPFdg8G631B0inWD9Z26YZNhG+RF/p5xAQC66e22sPLpEmHXtA1Ds0wuB4T4QGWHzo4xxCi1PEl7SiSqsKIqfqBYQM2UyyR7yulvxQpqPCgTnQhfEjv1UveBxeBGJMkeMLHPOXHANkp7ib/pcISWdiTa6VGghapuLnbZ0+d vgh2kWJG wUOnu6ad5oNb3dRypzjU5j9MyX8MeDS1nlZkgOCtdC+4aJtraJPTtph3D0rbNgXnk4IaXR8IUOJ0lG3cL7/UkwkjwEOCASTXySxEJdJcgcqp4okEk0UiIA9xTbZpBMad5Ya1LcvIq2zHvoyBW2P8BcnjlGOOQ3Ifv+qs4zJlvF7UnCcY83LdDUF1DhyYCsUoiM75BqtDg543r0lDjpiLge6kEagH/C+zeEwqMVSFXZ70TZB/EEozpUQpypVzUicABYmbW1/7w2hC1VPwilGH+nFk+XBGXg6/kuqxKrXsJhRNL40YV3RJEygNlCns+OMIWznJ8cQtmpC5bH3NPeSAAK4+4nj8UZTZLllmXYD3/0zs0IVCGS50AGIXI6JrQiz2X8UOzOd1txZ9V1PBJLU4jzARM7KXmTuz4tDS7NuxOWQSpWOXM/NblNlv62EnQjw++WARF/tBTgwey88/0TZVwLspMOT+QZ9x1mJZCF2tqVSGQzCGm6KHfRrJa4uTQU+rB8wUI X-Bogosity: Ham, tests=bogofilter, spamicity=0.000017, 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, 10 Aug 2024 at 05:21, Borislav Petkov wrote: > 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. That's the current process. The list of processes to be signalled is determined later and not in a simple way. > > > Supporting something generally includes supporting the common and the > > obscure cases. > > Bullshit. We certainly won't support some obscure use cases just > because. It's simple reliability, if you support something only sometimes no one can rely on it. Without a deep analysis of their kernel code snapshot at least. > > > 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? In the case I know of, by the parent process, it's basing some decision on the signal number and the expected behavior from the kernel even if not unambiguously documented. Like I said it can be worked around in userspace, my change doesn't *enable* the use case. Best regards