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 6AC74C25B78 for ; Wed, 22 May 2024 21:46:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D68306B00A2; Wed, 22 May 2024 17:46:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D17716B00A4; Wed, 22 May 2024 17:46:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BDFA76B00A5; Wed, 22 May 2024 17:46:21 -0400 (EDT) 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 A07AC6B00A2 for ; Wed, 22 May 2024 17:46:21 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 4EDC8850F6 for ; Wed, 22 May 2024 21:46:21 +0000 (UTC) X-FDA: 82147365762.23.87F8229 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf07.hostedemail.com (Postfix) with ESMTP id 47F874000D for ; Wed, 22 May 2024 21:46:19 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=f19+oMTl; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf07.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716414379; 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=0IPOkswwA/TJ9xaHowV/cvfG1H4kLvnXT+ET0mPfmoA=; b=lQORyAt6HgvYCGx5IMu/TtpbFsfCvqr/0Q6r9hXTWvTIcmaQdhNwjyHt6Z5ShE1vlT8hNJ 7TUpngHme3Oxp8yjM2Ex5/AktzHhWA0LWN7p6QHZFQyEwcACse9/0kPlrojb9x5M7/j0E+ lgm3x0wIBbox0O9oQ5aR7TtrEC2hnPs= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=f19+oMTl; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf07.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716414379; a=rsa-sha256; cv=none; b=RLIn/zlXjRF+1/wFn8V9BGnpoh3cIbYzndtHbWizB76pZPzKcxeEUL71xDZUSlpjvwY+9S PVVJxiDhCVBni3Nu345MatJ1phPBCgfPBcNCDIYSWoVdRHZoQWnGxmOxNQ8K1hsEoQ3BEc xuuuI5fFxA0J4KIga8M7E+oRVxnYrAU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1716414378; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0IPOkswwA/TJ9xaHowV/cvfG1H4kLvnXT+ET0mPfmoA=; b=f19+oMTlwqPAiwtzfzspNOctzG72bQBrAXt2L3YOuHF4XvaGPMcmlEDA2l4eGJNVLAeaHH 3wru3MoreECXo8OXyM3YpT1CY7wdrU5sF+2TFeDltP85FEqYVws5+/mf0f//+D7wPX7UN7 cHoW8m2X8qDwPSs0s8Yf+QxofWt8P9Q= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-329-zh8axOo0N-qqLWCasD6rgg-1; Wed, 22 May 2024 17:46:15 -0400 X-MC-Unique: zh8axOo0N-qqLWCasD6rgg-1 Received: by mail-qv1-f69.google.com with SMTP id 6a1803df08f44-6ab871c215fso2839656d6.3 for ; Wed, 22 May 2024 14:46:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716414375; x=1717019175; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0IPOkswwA/TJ9xaHowV/cvfG1H4kLvnXT+ET0mPfmoA=; b=aTsKSt3F+L6XKgMJXtcC6/GptvKZLTi38/JiX7zg5DgKZXoNeoTZJrd8Es5OaFAW43 52YpW4PQ2NW6O/Tt5KWWHt4B/+Vr+ccM7dvPtMTtuD70vQrpYycglQc/FToO+iQzKA4x 2dFsCVNCD4T4w3urJA8bQr2AI4u5Wupljb94gesK7YAhRrVLnooyb7ii/5GYgbMQcB0C r94xEpcEYYo2y6gbAAHscv/ogD6dS0N68bp/1607/4YvSa4QW8xXlr1HlfCw8VzqLZ+4 SuIX/+8YmGf7D+a3hXds5dMs+xQt4IX6bTCxiDsT8a1W8ZbQTXIFk//DwyoSvkeD1elQ kN6g== X-Forwarded-Encrypted: i=1; AJvYcCWrSJBmC+gXX+QfApVaa1gJlQf1Z7cTCO7R2kamJrzhSek4RzdvsuHrK9Yvk9vGrGa5AxdMbNmEvz9bzsiMHFTlfVo= X-Gm-Message-State: AOJu0YxgHsUSpY4DgKt4KsDizFVMt+F4P1bdNWtmuqTObE47GzFuy4Im IzTTaEslbYDAOs0LpeCn6A8OdwRTw3lIZC2zctQ/ZFPXFUqR+7Hhm3lSHwvfabWMuDrpU8klqcc Mx9teYDFYalCHf4IDdYxVOEbiEBRZZTaW47ibrpDHJDQo2UdV X-Received: by 2002:a05:6214:3004:b0:69b:1c6d:9a64 with SMTP id 6a1803df08f44-6ab80920651mr35047036d6.4.1716414374690; Wed, 22 May 2024 14:46:14 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFrpao2OsvBu8SGwX0VKGUdrFoO4tAR8Hf7zdwQnywyhHnT3+AiYwuxl3MoZyQZWINIE7Uy4g== X-Received: by 2002:a05:6214:3004:b0:69b:1c6d:9a64 with SMTP id 6a1803df08f44-6ab80920651mr35046606d6.4.1716414373600; Wed, 22 May 2024 14:46:13 -0700 (PDT) Received: from x1n (pool-99-254-121-117.cpe.net.cable.rogers.com. [99.254.121.117]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6a15f1cd266sm136827696d6.80.2024.05.22.14.46.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 May 2024 14:46:13 -0700 (PDT) Date: Wed, 22 May 2024 17:46:09 -0400 From: Peter Xu To: Oscar Salvador Cc: Axel Rasmussen , Andrew Morton , Andy Lutomirski , "Aneesh Kumar K.V" , Borislav Petkov , Christophe Leroy , Dave Hansen , David Hildenbrand , "H. Peter Anvin" , Helge Deller , Ingo Molnar , "James E.J. Bottomley" , John Hubbard , Liu Shixin , "Matthew Wilcox (Oracle)" , Michael Ellerman , Muchun Song , "Naveen N. Rao" , Nicholas Piggin , Peter Zijlstra , Suren Baghdasaryan , Thomas Gleixner , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org Subject: Re: [PATCH v2 1/1] arch/fault: don't print logs for pte marker poison errors Message-ID: References: <20240510182926.763131-1-axelrasmussen@google.com> <20240510182926.763131-2-axelrasmussen@google.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Queue-Id: 47F874000D X-Stat-Signature: 7p68k64p63ca6y9ambnwjfb9eg17f5me X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1716414379-97461 X-HE-Meta: U2FsdGVkX18fsoDoJudBhAWB4ChOGoA70RWSz6+2Hn0F9fymoXqLhNaXoCT/vvyfpTiyw9kHn1EJU+DgGOcwwuta8LgPECt6c+NEzHN1vagwUQxE+ARpZhSZDA6xQVIBozBfwpqE+PKA0UTLEGfB6cHXorAPKPBtMrpfgYH8WrhcrBFrZTfsIghYPfPXzccPbpIdjKAmqNEK0M2tiRme+NxQvOZ2xOXVI2ZdJ2QuTdC3Fm0MkvEfCmpLH7+pBbrWPArCt23XUnPPOCzTq5MwsTX/cjfrqXAnIKX/UXcvYLJ1J/QG1h1c2MRB6LhfHDYGLOXAzNyKeYOghXk0ouCTZWNDlLb0sV+fbAYFr4XR6H18xu8cgp5iVyaECv3C41zqmtbgzYqVUXRqBhvwRwZPUJNTWttyD1Qm3UZLUEOuvk4Jo2OHIz+0WSHez0QfcmKcx7Yj3R5RIrfhklqA6E7bA/qyQEq6FauuGEsGdR/2aeu42jDm3Z1x6OxrjWM3eOuk+NOlUd+Hrwd6UUehS6Xrx+nlHrHlHdUoyM/L6zec2pFCiLmkSa4qWK8A7b/ASTOsnVYLA35m1GSqduVbN+UafcL2rkgt6Ni2Tk0ikG33tZiRaDoT8fndJ5se3PMmKV3KS5x+oOBJJ8A7m+MT19ivO4QwBSmrHGBihlglcTcrP4HdMtkdhbvzo21A4xdGUCsAPLfq39O8mpZR5TChrzZeGsFeEExMIxJsKQz4eplkbfigKNTv0EE3ePeCamGD2gKTf1OAzkXE7LLoLhjs6FmT4BfhkQOVRl4T/f72qouD3JAKEp7S4ZOXAw8ODNCjyo4WaLeQvrQet9wLvtXnWeIXYvnKZFZcWeP6eL2cyH6M3ctozOfX7SfZww3RJfSv/fkUWyX6j3AZQ5fOwB0szHynnUKb1XmoJhncDTkGjXyvbKOp/05aXy6doCLDD20RZae7jhFbHCL8GcfQnxcej1g Ks7s90Th aQ9BZVc5n00m6Hlg2LMrcR3lcyouZ9BROaRcJ1ZlTHm+WGAsGREiwmnwulI1WQEaCRnfXi7GJA6TUnFFIMo5Dc+PzocFik5JX4hTglIcGOkAYABKmCgxuct4LC44Rdhax4Vz3/9mR81CTJgGjCuKerfYUuLY2jCVWmjArjHSK8vaksTuvQr6EJisTn4sdkVC7YdDDsphPqmFgYgs9rcb5N7wMTXbt7HkalASiI+WYnLGP7Cph1M4ZM/9lyatfPcfq5nGp/AFn79bR5Bsi5aQXaFRTIelXiQE8NWJmZ0eqvkJ3gWUEUTBMHuYLDAZ/jeK5s4qPprom9s6dewzZvSa0ZqPvPQjZuXxXvL+HzG8Nl7nbBmLlP3jhQMVnNFeZcYNebWNsfOXpCXm2svk= 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: On Wed, May 15, 2024 at 12:21:51PM +0200, Oscar Salvador wrote: > On Tue, May 14, 2024 at 03:34:24PM -0600, Peter Xu wrote: > > The question is whether we can't. > > > > Now we reserved a swp entry just for hwpoison and it makes sense only > > because we cached the poisoned pfn inside. My long standing question is > > why do we ever need that pfn after all. If we don't need the pfn, we > > simply need a bit in the pgtable entry saying that it's poisoned, if > > accessed we should kill the process using sigbus. > > > > I used to comment on this before, the only path that uses that pfn is > > check_hwpoisoned_entry(), which was introduced in: > > > > commit a3f5d80ea401ac857f2910e28b15f35b2cf902f4 > > Author: Naoya Horiguchi > > Date: Mon Jun 28 19:43:14 2021 -0700 > > > > mm,hwpoison: send SIGBUS with error virutal address > > > > Now an action required MCE in already hwpoisoned address surely sends a > > SIGBUS to current process, but the SIGBUS doesn't convey error virtual > > address. That's not optimal for hwpoison-aware applications. > > > > To fix the issue, make memory_failure() call kill_accessing_process(), > > that does pagetable walk to find the error virtual address. It could find > > multiple virtual addresses for the same error page, and it seems hard to > > tell which virtual address is correct one. But that's rare and sending > > incorrect virtual address could be better than no address. So let's > > report the first found virtual address for now. > > > > So this time I read more on this and Naoya explained why - it's only used > > so far to dump the VA of the poisoned entry. > > Well, not really dumped, but we just pass the VA down the chain to the > signal handler. > > But on the question whether we need the pfn encoded, I am not sure > actually. > check_hwpoisoned_entry() checks whether the pfn where the pte sits is > the same as the hwpoisoned one, so we know if the process has to be > killed. > > Now, could we get away with using pte_page() instead of pte_pfn() in there, and > passing the hwpoisoned page instead ot the pfn? > I am trying to think of the implications, then we should not need the > encoded pfn? I sincerely don't know; we need help from someone know better on hwpoison, maybe. It's at least not needed in fault paths, afaiu. > > > However what confused me is, if an entry is poisoned already logically we > > dump that message in the fault handler not memory_failure(), which is: > > > > MCE: Killing uffd-unit-tests:650 due to hardware memory corruption fault at 7f3589d7e000 > > > > So perhaps we're trying to also dump that when the MCEs (points to the same > > pfn) are only generated concurrently? I donno much on hwpoison so I cannot > > tell, there's also implication where it's only triggered if > > MF_ACTION_REQUIRED. But I think it means hwpoison may work without pfn > > encoded, but I don't know the implication to lose that dmesg line. > > Not necesarily concurrently, but simply if for any reason the page could > not have been unmapped. > Let us say you have ProcessA and ProcessB mapping the same page. > We get an MCE for that page but we could not unmapped it, at least not > from all processes (maybe just ProcessA). > > memory-failure code will mark it as hwpoison, now ProcessA faults it in > and gets killed because we see that the page is hwpoisoned in the fault > path, so we sill send VM_FAULT_HWPOISON all the way down till you see > the: > > "MCE: Killing uffd-unit-tests:650 due to hardware memory corruption > fault at 7f3589d7e000" from e.g: arch/x86/mm/fault.c:do_sigbus() > > Now, ProcessB still has the page mapped, so upon re-accessing it, > it will trigger a new MCE event. memory-failure code will see that this The question is why accessing that hwpoison entry from ProcB triggers an MCE. Logically that's a swap entry and it should generate a page fault rather than MCE. Then in the pgfault hanlder we don't need that encoded pfn as we have vmf->address. > page has already been marked as hwpoisoned, but since we failed to > unmap it (otherwise no one should be re-accessing it), it goes: "ok, > let's just kill everybody who has this page mapped". > > > > We used to not dump error for swapin error. Note that here what I am > > saying is not that Axel is doing things wrong, but it's just that logically > > swapin error (as pte marker) can also be with !QUIET, so my final point is > > we may want to avoid having the assumption that "pte marker should always > > be QUITE", because I want to make it clear that pte marker can used in any > > form, so itself shouldn't imply anything.. > > I think it would make more sense if we have a separate marker for swapin > errors? > I mean, deep down, they do not mean the same as poison, right? > > Then you can choose which events get to be silent because you do not > care, and which ones need to scream loud. > I think swapin errors belong to the latter. At least I a heads-up why a > process is getting killed is appreciated, IMHO. Right it can be separate, and that was the plan IIRC. But maybe an overkill for now if nobody cared, and we can wait until someone really cares about that. After all adding a dmesg line for such event is much easier than removing one.. Thanks, -- Peter Xu