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 2F348C433EF for ; Fri, 10 Jun 2022 08:57:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 922A16B0116; Fri, 10 Jun 2022 04:57:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8D28D6B0117; Fri, 10 Jun 2022 04:57:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 799526B0118; Fri, 10 Jun 2022 04:57:35 -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 6BA456B0116 for ; Fri, 10 Jun 2022 04:57:35 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 3965134BB3 for ; Fri, 10 Jun 2022 08:57:35 +0000 (UTC) X-FDA: 79561722870.30.0F52930 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf15.hostedemail.com (Postfix) with ESMTP id 7EA0DA005E for ; Fri, 10 Jun 2022 08:57:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1654851454; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xTWibueTmngdj/xrifw+G1kLc6wzYjVJd13reaabSIc=; b=f743vjtFofbciyay5UF1YS0DS31zLCjEX/1z11sCiLWToLC3kAPn8yxKgWNxQhEAN8i0Mw jS1pOZInWZOnCFKhFBKevqjqTVLeqFuj4MGdSjKZRmGbf0Nx8VrwyiKQMyv1uW/D7nr/ml oiOwpnGl2Yliw4+63HjSo2pSONEnvUs= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-21-QZgBk-U3O_uFMEnOmJlzSQ-1; Fri, 10 Jun 2022 04:57:32 -0400 X-MC-Unique: QZgBk-U3O_uFMEnOmJlzSQ-1 Received: by mail-wm1-f71.google.com with SMTP id ay28-20020a05600c1e1c00b0039c5cbe76c1so1024467wmb.1 for ; Fri, 10 Jun 2022 01:57:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=xTWibueTmngdj/xrifw+G1kLc6wzYjVJd13reaabSIc=; b=ag9CK9Xqh7+S07vwlcra4B21LlIsNGOrQboKJsfpXN3U6kYtRsQAPxfeHxKhUU6SUE Y2vvkdWliPeIljQJo6JAuBTyvs2wR8PIzhTyFWQd7selePFEh5mMdI5/sEE+zGssu+WI oLHqBTiGHgYGO1GAlb+0fi2fnXrBNFT0tnNrcJwaqXuxDZBMrqbL1qnfPOkN/B6NUwlW jIB4pkY2ip+Vb5nzYtkWMdQJeOAQhifLrviDBi40IqjwHKIJayTCQHjxk/8KHMqtI/dq IV8i8obcJSnTl889/WkzOhjx1G3XyvShBHaKY3lGBz96AO20PXG2kbQSLF8/woNueN99 iNMA== X-Gm-Message-State: AOAM531AxaGf1GNGiaQEaKv4SGq8XSN0kBKWDFLWHfNABnR0Pga/qsv2 ZUrrEtLsW+ZBYmpqqYVG68qptf9QV9l+iMVe5PNHlHQ7QWTiv2La10yAP/XsXCznoEq03Kqmpgm gkJEakRhGqPI= X-Received: by 2002:a05:600c:1ca0:b0:39c:4dbd:e9ed with SMTP id k32-20020a05600c1ca000b0039c4dbde9edmr7659433wms.40.1654851451382; Fri, 10 Jun 2022 01:57:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy9gPwJbMWqqdj9HjxvxEPPxNvmExqSzJ0nBlmICif9ZArE+TzhG8FV2J0O8kN951M8VxsgLA== X-Received: by 2002:a05:600c:1ca0:b0:39c:4dbd:e9ed with SMTP id k32-20020a05600c1ca000b0039c4dbde9edmr7659416wms.40.1654851451049; Fri, 10 Jun 2022 01:57:31 -0700 (PDT) Received: from ?IPV6:2003:cb:c705:1f00:4727:6420:1d4d:ca23? (p200300cbc7051f00472764201d4dca23.dip0.t-ipconnect.de. [2003:cb:c705:1f00:4727:6420:1d4d:ca23]) by smtp.gmail.com with ESMTPSA id z5-20020a7bc145000000b0039763d41a48sm2153407wmi.25.2022.06.10.01.57.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Jun 2022 01:57:30 -0700 (PDT) Message-ID: Date: Fri, 10 Jun 2022 10:57:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 To: zhenwei pi , akpm@linux-foundation.org, naoya.horiguchi@nec.com Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20220608084356.40894-1-pizhenwei@bytedance.com> <20220608084356.40894-2-pizhenwei@bytedance.com> <260b719b-9138-9615-fae4-b5b4c86674a2@redhat.com> <66cc45e6-0947-d991-af81-d56eb708f5b0@bytedance.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v2 1/1] mm/memory-failure: don't allow to unpoison hw corrupted page In-Reply-To: <66cc45e6-0947-d991-af81-d56eb708f5b0@bytedance.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1654851454; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=xTWibueTmngdj/xrifw+G1kLc6wzYjVJd13reaabSIc=; b=qxMCh/uslIRjUfYReWzoKs3q8frJaXRKQBHVO6Jp/jYx9wXlgnCWiKTZm7/Kk5T1GXkMZm Cu72w5U090IjeNEZfl0sediPVhsrGRCsAZDMGkmacmpK5x/+SXhEXyO8+rEg3p8g5AL8u0 njf8p8FimX4+ukOa8iP4PZAv/X9oUO4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1654851454; a=rsa-sha256; cv=none; b=JfqsG5dtKBJEfPi3nBELq2rwyzQt27xIhFzqAvGidtRkE4XEzaMbDBN44re/kWPpHTMH31 fo8/FnMcQyDUS1q1yc/K7Lozo1ZPejarhoXQfvpA2ufn/9DRQVg+binmp28OAvoz1WeZWI XHrKns7IaTfUvgps0uIMmCFqkqxfe6U= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=f743vjtF; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf15.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=f743vjtF; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf15.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com X-Rspamd-Server: rspam08 X-Rspam-User: X-Stat-Signature: 4pa5j4y4axo5hk5idfecc5o3onroaoka X-Rspamd-Queue-Id: 7EA0DA005E X-HE-Tag: 1654851454-564710 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: On 10.06.22 07:06, zhenwei pi wrote: > > > On 6/8/22 17:30, David Hildenbrand wrote: >> On 08.06.22 10:43, zhenwei pi wrote: >>> Currently unpoison_memory(unsigned long pfn) is designed for soft >>> poison(hwpoison-inject) only. Since 17fae1294ad9d, the KPTE gets >>> cleared on a x86 platform once hardware memory corrupts. >>> >>> Unpoisoning a hardware corrupted page puts page back buddy only, >>> the kernel has a chance to access the page with *NOT PRESENT* KPTE. >>> This leads BUG during accessing on the corrupted KPTE. >>> >>> Do not allow to unpoison hardware corrupted page in unpoison_memory() to >>> avoid BUG like this: >>> >>> Unpoison: Software-unpoisoned page 0x61234 >>> BUG: unable to handle page fault for address: ffff888061234000 >>> #PF: supervisor write access in kernel mode >>> #PF: error_code(0x0002) - not-present page >>> PGD 2c01067 P4D 2c01067 PUD 107267063 PMD 10382b063 PTE 800fffff9edcb062 >>> Oops: 0002 [#1] PREEMPT SMP NOPTI >>> CPU: 4 PID: 26551 Comm: stress Kdump: loaded Tainted: G M OE 5.18.0.bm.1-amd64 #7 >>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ... >>> RIP: 0010:clear_page_erms+0x7/0x10 >>> Code: ... >>> RSP: 0000:ffffc90001107bc8 EFLAGS: 00010246 >>> RAX: 0000000000000000 RBX: 0000000000000901 RCX: 0000000000001000 >>> RDX: ffffea0001848d00 RSI: ffffea0001848d40 RDI: ffff888061234000 >>> RBP: ffffea0001848d00 R08: 0000000000000901 R09: 0000000000001276 >>> R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000001 >>> R13: 0000000000000000 R14: 0000000000140dca R15: 0000000000000001 >>> FS: 00007fd8b2333740(0000) GS:ffff88813fd00000(0000) knlGS:0000000000000000 >>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>> CR2: ffff888061234000 CR3: 00000001023d2005 CR4: 0000000000770ee0 >>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 >>> PKRU: 55555554 >>> Call Trace: >>> >>> prep_new_page+0x151/0x170 >>> get_page_from_freelist+0xca0/0xe20 >>> ? sysvec_apic_timer_interrupt+0xab/0xc0 >>> ? asm_sysvec_apic_timer_interrupt+0x1b/0x20 >>> __alloc_pages+0x17e/0x340 >>> __folio_alloc+0x17/0x40 >>> vma_alloc_folio+0x84/0x280 >>> __handle_mm_fault+0x8d4/0xeb0 >>> handle_mm_fault+0xd5/0x2a0 >>> do_user_addr_fault+0x1d0/0x680 >>> ? kvm_read_and_reset_apf_flags+0x3b/0x50 >>> exc_page_fault+0x78/0x170 >>> asm_exc_page_fault+0x27/0x30 >>> >>> Fixes: 847ce401df392 ("HWPOISON: Add unpoisoning support") >>> Fixes: 17fae1294ad9d ("x86/{mce,mm}: Unmap the entire page if the whole page is affected and poisoned") >>> Cc: Naoya Horiguchi >>> Signed-off-by: zhenwei pi >>> --- >>> mm/memory-failure.c | 9 +++++++++ >>> 1 file changed, 9 insertions(+) >>> >>> diff --git a/mm/memory-failure.c b/mm/memory-failure.c >>> index b85661cbdc4a..da99a2b7ef35 100644 >>> --- a/mm/memory-failure.c >>> +++ b/mm/memory-failure.c >>> @@ -2090,6 +2090,7 @@ int unpoison_memory(unsigned long pfn) >>> { >>> struct page *page; >>> struct page *p; >>> + pte_t *kpte; >>> int ret = -EBUSY; >>> int freeit = 0; >>> static DEFINE_RATELIMIT_STATE(unpoison_rs, DEFAULT_RATELIMIT_INTERVAL, >>> @@ -2103,6 +2104,14 @@ int unpoison_memory(unsigned long pfn) >>> >>> mutex_lock(&mf_mutex); >>> >>> + kpte = virt_to_kpte((unsigned long)page_to_virt(p)); >>> >> I'm curious whether virt_to_kpte is sane to use, especially, when having >> the direct map map PMDs and not PTEs? >> >> virt_to_kpte() only checks for pmd_none() -- but what if we have >> pmd_large()? >> >> Naive me would assume that calling virt_to_kpte() from generic code is >> broken. Only mm/highmem.c uses it, however, 32bit most probably also >> doesn't have large mappings in the page tables for the direct map. >> > > Hi, > > I dived into this part and noticed that both pmd_off_k() and > virt_to_kpte() are broken. > > For example, on a x86 platform, if the CPU has feature 'pdpe1gb', the > kernel prefers 1G map. (cat /proc/meminfo | grep DirectMap to show the > current mapping) > > static inline pmd_t *pmd_off_k(unsigned long va) > { > return pmd_offset(pud_offset(p4d_offset(pgd_offset_k(va), va), > va), va); > } > > There is no pud_none() & pud_large()(of cause, we can't use pud_large() > here) to test *PUD* valid or not. > > So I'm going to do: > - in pmd_off_k(), use pud_none() and pud_bad() to test *PUD*, if failed, > BUG(). > - in virt_to_kpte(), use pmd_none() & pmd_bad() to test *PMD*, if > failed, BUG(). > - rework KPTE test in unpoison_memory(), walk page table instead of > useing virt_to_kpte(). > > Do you have any suggestions? > TBH, I am not convinced that this is worth the trouble. You have to win the lottery and get a MCE use a pure debugging interface to clear a hwpoisoned page that was not previously poisoned via that debugging interface. There are easier ways to crash the kernel if one is explicitly looking for trouble on a debug kernel. Further, this looks very x86 specific to me. The whole detection is unreliable if the arch doesn't do this unmapping, and neither your patch subject nor the new error message holds reliably. Even further, what if the hw error triggered memory_failure() which set SetPageHWPoison(), but that failed? We won't be unmapping anything, still, you'd be able to clear that because it could look like a software poisoned page, no? Last but not least: what if some other arch requires yet some other handling for hw poisoned pages that we are not covering here? Instead of seeing more widespread use of virt_to_kpte() and friends I'd much rather see all of that "generic" only-works-on-random-32bit-arch stuff removed. I am not even sure if we even *need* that unpoisoning complexity just for some debugging/testing activity. 847ce401df39 ("HWPOISON: Add unpoisoning support") mentions: "The unpoisoning interface is useful for stress testing tools to reclaim poisoned pages (to prevent OOM)". Why can't these tools simply reboot once we reach a certain #hwpoisoned pages? It's certainly a lot easier then having kernel support for something that cannot happen in "real" environments. So if anything, I'd vote for removing that interface+complexity, or alternatively *disabling* it once we have a hw triggered poisoning. -- Thanks, David / dhildenb