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 D2E9CC04FFE for ; Tue, 14 May 2024 21:34:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5465B6B036F; Tue, 14 May 2024 17:34:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4D8A56B0370; Tue, 14 May 2024 17:34:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3230F6B0371; Tue, 14 May 2024 17:34:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 0FCA96B036F for ; Tue, 14 May 2024 17:34:38 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 8AE21160247 for ; Tue, 14 May 2024 21:34:37 +0000 (UTC) X-FDA: 82118305794.30.227ADD4 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf16.hostedemail.com (Postfix) with ESMTP id 72F31180017 for ; Tue, 14 May 2024 21:34:35 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Qt+g5LAX; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf16.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.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=1715722475; 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=Q2Xu6ycBxA1ncNcxZjTIGSkpvUsVz0mp4Jxa+4CoWmo=; b=DWOOBjVv2A+fqUARklBrZInPrCIVsY6SszTzz92VhLVWsJJzGgbTr8vGK4EjD+YOUPl8JS Vrh53JOZGTzgFMqmTkTgj8Qbb1WUCCIMK+qoIQPsiqySbuoYm0Og3LluJ1LR2zcsCBrRuU tg11+27XV89P0eENpQ+hTOBmbKc+JaY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715722475; a=rsa-sha256; cv=none; b=oU46xBCPAdQHi/QbhamLReUpodqTEqZ0D5opGCCyludZUEi0p+VVBcTiGPn+NBxbo7KweV 76N9eAU8crRl5y18WFNNSX4lsD0WD+Vx7G6O9AxAYMsxz1molAU5RrjjgiHkNOmtxX/Acp 6Et+U1ZDAP6bDIbPq7s1L5NjCGgkVkQ= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Qt+g5LAX; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf16.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1715722474; 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=Q2Xu6ycBxA1ncNcxZjTIGSkpvUsVz0mp4Jxa+4CoWmo=; b=Qt+g5LAXVIO5xzH4Z0SI/Eu4aN0Jq8Nh/WY9pNM/AeN3IvdW/8YAIUFymEkia/MIoKmDNb 9iWCdGcOOGj2p+/flfSaiGOEBSn3N3UGsYMfjGnOg3xXHmxO76q9rNtnb3e7XkDxkfQf/U CE7idvKepZuIhZ991r6CW036qOgksog= Received: from mail-pj1-f71.google.com (mail-pj1-f71.google.com [209.85.216.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-664-GxEhsGqEMUmkdUEiCWSugQ-1; Tue, 14 May 2024 17:34:33 -0400 X-MC-Unique: GxEhsGqEMUmkdUEiCWSugQ-1 Received: by mail-pj1-f71.google.com with SMTP id 98e67ed59e1d1-2b83ee6ef60so1484746a91.2 for ; Tue, 14 May 2024 14:34:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715722472; x=1716327272; 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=Q2Xu6ycBxA1ncNcxZjTIGSkpvUsVz0mp4Jxa+4CoWmo=; b=JM6CksVxt78T1Lp6z9fMSi+7A0gbJj+tAMQ5MD7jKXdAYnRlZ2Wl6tq3Tnz7MXXEIM l2LVFyD1QneeDqbt9Taxiu1KFHCawHNW8vj0gzdcQ2jB97E43P7FOj8uRPElI5LIsCQb mM3bz7nidMVUnt8UlNkLV4rp66L4mMq96uBTmp9/XRGPRW4JkoJK5LniL1wDWEXGKkl4 ad04q6IjxKqj0d9t1NyWp7n2fPh8agJRYoR68NVSuhTLKqPjJaz9rUKtXDH0Yds3n/r2 YBAZ0ohx8znNqscxXFUMOaK9E4FsQJufxvXVB1liNjn08nf7b2Wj8Mi4XZkE3phfxuZL 2+7g== X-Forwarded-Encrypted: i=1; AJvYcCV2aVFUCF4ciRQcRODakhcB9oc8Ar4zAHBVidtDHRkMv/RA9ogEvR9ZZ/ZjKk0CD+JjoCG+qycDB/v5pzClyPV6sbE= X-Gm-Message-State: AOJu0YyISlgoWUYWUnC2TMq3OEisb0436M6+/6dVAOszW75v1cJWW9iK j/ohKsv6YpYIkkxnU6DKJuwzRkqbYy6Kub0E9JLoPJq6kULGLQcSKMK6gR/vvCsYg+bpp+2QGeQ gJn8so2zV7fIbXdP3t1z4Afe8yeVH8kWjSqbD8wMYdR2+rKsE X-Received: by 2002:a17:903:246:b0:1eb:50eb:c07d with SMTP id d9443c01a7336-1ef441aa0a2mr161489415ad.4.1715722472125; Tue, 14 May 2024 14:34:32 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGlPBl9ea4KstMsjdvAfVmaII4uiOPY4sbbUGcaeXkU+KlSg8op9ntpdI4qQN60DSBg7ZfBtw== X-Received: by 2002:a17:903:246:b0:1eb:50eb:c07d with SMTP id d9443c01a7336-1ef441aa0a2mr161488855ad.4.1715722471349; Tue, 14 May 2024 14:34:31 -0700 (PDT) Received: from x1n ([50.204.89.32]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1ef0bad9da4sm102645805ad.107.2024.05.14.14.34.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 May 2024 14:34:30 -0700 (PDT) Date: Tue, 14 May 2024 15:34:24 -0600 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-Stat-Signature: mf3gbhszz8xycdzpasbnk9ndmkqhac9g X-Rspamd-Queue-Id: 72F31180017 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1715722475-998495 X-HE-Meta: U2FsdGVkX19sQMkgOSesfnSulRKeQ1kp8reZoZH+bilektNpbLkf41bJ4gCEGOoq39K5TEQuoCeFmMSsP2UvHo41AGG2sIljBSZG1n0QXsVUtU5bZge5OeBtrf6ppTaWHQfxg0BJ1blR8DaQxXuv7tYBXCuyWbFdwbozWhuejm5cnYGqyZLvt8hQcIUoXVJ0cLBNt9SJQ8d1S1TWqgHxsNq1yZ8/Yq/zM3A5Evwtl3cydbQ/gJphg5kWH5AV9+vsICGZFa4p6NTSGgBeZTaZie3FmSrVrPmKOjDhv4AR4QhaCPNJZ6X2SQ91gpw600OKXpGeRDGHNEAMeK6qE88Y7jHPasOvxwXXPE60dh4nmT9W8nrAoYpzhNr1jh9UjueSLWdWpFi8mSNWSjCyCHvPGhcti0NNE3K9yvYwENpH12FBxh6OPUsh0QZZtAWAn27JBhmACcXnxk/tiXTz4vYAWGwOODv1ylS32uSlbdMbO+dkzWQ+X3Q1MlDgj0ttpTtdQPr+4spxbycdEXAafbGUjJRVZPH7TGTQlLm2QQGPFYUC/rGDR4UAJdD0DOFe/bCTU/33iHyyaf9QznPDLgGkWBl9gyggrfdIjDK3VyOuFaywrSqaaCwtIWnD5r/KcpeDzbSVD6o6YTTHsnl7zetXKUOZT2I4zNyEGTqO3kIFv7dYzm83/f33tzJPhGgh39OkzKiSgB7Yfl0nEchTGhpKVMHuOTg05kDfwJGnOVccMHaDvJFqaQM8KFpboLVkUiw0Q5PS95+RQD335oHOoOeAIoiiGptegCE0sAEJZ4G/OGsMEFB5lsYZWlIhUTeDEZyrmUmniCEYZm8HpB96ywn9VoQmJqAwLFLvAoA6w8PlK1JZk5njpLsPTn66iiCiJnr8bk3Ho/YueLWPccqtMqkv/QbLvdew5fI5/J/RsSGVOXf6GgUMTyZ+dCfcNdJsE2TqECM3JGGl4cZD2ZABT6B ZncIlA7W PXqz40K3fvVSwdbJ5hVr+7u9YBIFdOwNVtT9u3INHLMJqKqghQaAd+0vvW+fHHJSj6qQF2svVgDraoW9j5GLlPrf2TZJIKOqBf64mivRHDWd5y2Y/nvMr+jXUr+tFq8kVCAXGBruzJsyGrntl4M1zJGwKR57Oh73iimPQa3aVsrnvHVUMAi2y2bxbTwt93x2SZBu8P+Biyaluwy7hEDcs526xcf4zjqfK+5AzXsXEB0JKc2Y8coUc+FcnBeNd8YwapIF/r9880wDFusJsQhcKdguUxWpuNOWF86Jq1BsSqwTWjewTm96N5uXEiC5hrC5YzxKYVSbwSr979GVYC9elPcyX+OkKo1ePFk0XpDYhOE2lURv08mMWnTbLkiS4rhPn+BRG6h0WgQ7FolBaTE01IZEyAugb+CQVCN+OdtohjXTnF9Qq+XtQum34pw== 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 Tue, May 14, 2024 at 10:26:49PM +0200, Oscar Salvador wrote: > On Fri, May 10, 2024 at 03:29:48PM -0400, Peter Xu wrote: > > IMHO we shouldn't mention that detail, but only state the effect which is > > to not report the event to syslog. > > > > There's no hard rule that a pte marker can't reflect a real page poison in > > the future even MCE. Actually I still remember most places don't care > > about the pfn in the hwpoison swap entry so maybe we can even do it? But > > that's another story regardless.. > > But we should not use pte markers for real hwpoisons events (aka MCE), right? 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. 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. > I mean, we do have the means to mark a page as hwpoisoned when a real > MCE gets triggered, why would we want a pte marker to also reflect that? > Or is that something for userfaultd realm? No it's not userfaultfd realm.. it's just that pte marker should be a generic concept, so it logically can be used outside userfaultfd. That's also why it's used in swapin errors, in which case we don't use anything else in this case but a bit to reflect "this page is bad". > > > And also not report swapin error is, IMHO, only because arch errors said > > "MCE" in the error logs which may not apply here. Logically speaking > > swapin error should also be reported so admin knows better on why a proc is > > killed. Now it can still confuse the admin if it really happens, iiuc. > > I am bit confused by this. > It seems we create poisoned pte markers on swap errors (e.g: > unuse_pte()), which get passed down the chain with VM_FAULT_HWPOISON, > which end up in sigbus (I guess?). > > This all seems very subtle to me. > > First of all, why not passing VM_FAULT_SIGBUS if that is what will end > up happening? > I mean, at the moment that is not possible because we convolute swaping > errors and uffd poison in the same type of marker, so we do not have any > means to differentiate between the two of them. > > Would it make sense to create yet another pte marker type to split that > up? Because when I look at VM_FAULT_HWPOISON, I get reminded of MCE > stuff, and that does not hold here. 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.. Thanks, -- Peter Xu