From nobody Mon Apr 20 01:09:47 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E0853C433EF for ; Thu, 23 Jun 2022 23:52:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231173AbiFWXwg (ORCPT ); Thu, 23 Jun 2022 19:52:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56534 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231169AbiFWXwc (ORCPT ); Thu, 23 Jun 2022 19:52:32 -0400 Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8095C60C45 for ; Thu, 23 Jun 2022 16:52:31 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id jh14so636865plb.1 for ; Thu, 23 Jun 2022 16:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=guCk9+fmq044uYhThIHO4V934ZX2nYq8f94Emgz8GLM=; b=SUGUBrBFD30w/LODLPszAIWFJuyzy0h8yKc3XwFCVTjTpmAqYwYtNybMHRZ+ghsnt6 oFA4URHrauTUulNAvk0QCM67P/nkIVpijwPqu2IdFqBueiiaMSAQRPwpv6i3r+6CFCg5 plfgyMDGoKKdV7nNouU2+OWjZzQEV8GM9uqudK4CYp5wzLwGI5Uhh02fmt9opzL/hOuQ CHb2xiFPkQFAEUzJn7vUfUw/CjDKDoPj4aI+IY/+fKamjEPVD1pKTCLT8ivMhoUVoJNj HHF6gHkYy+hsHX3Jl6+v2yJCbU1tOMvmcYoLzEGZK1goInD5vx4s9WLc/yecqlQhAZqt O+OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=guCk9+fmq044uYhThIHO4V934ZX2nYq8f94Emgz8GLM=; b=p1EJjJitwRENom3Z6JKLfo0opFzzfQ1cvYrlr9DAsAWyFhDjs6QcpQL1uY7BnOwf1F THoqLC55z7sPrwAo+vRY7jAHTCRIdVuHE4mKUUIMgQP3ydFFZ1G+lwLtQgF5/n9Qp0NN UzUvSCfKga9+ppOVwTtks5gkfRYQb4yLE0vEqmfpnh9kXKwQAylsDh1uMlD/jcG1D1R3 mOuzgcCohb+Lhw/ww1rLGqTsA9YG4k9meywVrsPA+qYUczBKDxccbo6D8AxxyMAMCt7j nHFFV8YKfFCZwUMIQSPubb+nFTIvk4EZ6sRipJU3NaGVnUUcHHnv6YvFj5HyOTPII+9+ HS/Q== X-Gm-Message-State: AJIora/bDabQFOxZThaRKsT149iibn+EGCDJtg2TonmdfKtVDqgaw+96 2CcObBZuU0sgvRl/LhIyXw== X-Google-Smtp-Source: AGRyM1vkLEUzFkCo4X+WONweFksRrl4oFKOzMvGjQX9HHb/bP3CF+/JL7adCPfO4KW6Vp/9kEJ5QLg== X-Received: by 2002:a17:90b:1a8c:b0:1ed:1afb:7a73 with SMTP id ng12-20020a17090b1a8c00b001ed1afb7a73mr571077pjb.144.1656028351028; Thu, 23 Jun 2022 16:52:31 -0700 (PDT) Received: from ik1-406-35019.vs.sakura.ne.jp (ik1-406-35019.vs.sakura.ne.jp. [153.127.16.23]) by smtp.gmail.com with ESMTPSA id r10-20020a170903020a00b00168eab11f67sm362571plh.94.2022.06.23.16.52.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jun 2022 16:52:30 -0700 (PDT) From: Naoya Horiguchi X-Google-Original-From: Naoya Horiguchi To: linux-mm@kvack.org Cc: Andrew Morton , David Hildenbrand , Mike Kravetz , Miaohe Lin , Liu Shixin , Yang Shi , Oscar Salvador , Muchun Song , Naoya Horiguchi , linux-kernel@vger.kernel.org Subject: [PATCH v2 1/9] mm/hugetlb: remove checking hstate_is_gigantic() in return_unused_surplus_pages() Date: Fri, 24 Jun 2022 08:51:45 +0900 Message-Id: <20220623235153.2623702-2-naoya.horiguchi@linux.dev> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220623235153.2623702-1-naoya.horiguchi@linux.dev> References: <20220623235153.2623702-1-naoya.horiguchi@linux.dev> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Naoya Horiguchi I found a weird state of 1GB hugepage pool, caused by the following procedure: - run a process reserving all free 1GB hugepages, - shrink free 1GB hugepage pool to zero (i.e. writing 0 to /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages), then - kill the reserving process. , then all the hugepages are free *and* surplus at the same time. $ cat /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages 3 $ cat /sys/kernel/mm/hugepages/hugepages-1048576kB/free_hugepages 3 $ cat /sys/kernel/mm/hugepages/hugepages-1048576kB/resv_hugepages 0 $ cat /sys/kernel/mm/hugepages/hugepages-1048576kB/surplus_hugepages 3 This state is resolved by reserving and allocating the pages then freeing them again, so this seems not to result in serious problem. But it's a little surprizing (shrinking pool suddenly fails). This behavior is caused by hstate_is_gigantic() check in return_unused_surplus_pages(). This was introduced so long ago in 2008 by commit aa888a74977a ("hugetlb: support larger than MAX_ORDER"), and it seems to me that this check is no longer unnecessary. Let's remove it. Signed-off-by: Naoya Horiguchi --- mm/hugetlb.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index a57e1be41401..c538278170a2 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -2432,10 +2432,6 @@ static void return_unused_surplus_pages(struct hstat= e *h, /* Uncommit the reservation */ h->resv_huge_pages -=3D unused_resv_pages; =20 - /* Cannot return gigantic pages currently */ - if (hstate_is_gigantic(h)) - goto out; - /* * Part (or even all) of the reservation could have been backed * by pre-allocated pages. Only free surplus pages. --=20 2.25.1 From nobody Mon Apr 20 01:09:47 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 549BECCA47C for ; Thu, 23 Jun 2022 23:52:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231208AbiFWXwj (ORCPT ); Thu, 23 Jun 2022 19:52:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56572 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231182AbiFWXwg (ORCPT ); Thu, 23 Jun 2022 19:52:36 -0400 Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8FA2960C40 for ; Thu, 23 Jun 2022 16:52:34 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id x4so1070349pfq.2 for ; Thu, 23 Jun 2022 16:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=l+d0OGtRtkY09M0VLBofFywNSItSfbSemC3EkYMtQyY=; b=ou1qFSPl8LCvTmp9oUsKtEu26AbVApYmilkjIi5Rqdhn7tRx0awXZilRcMS07UUquu QsIs67X8QqsYXNyNzHjQNz4bMesy8pxAo3Bce4yXtWS4IsYr//Q6obb1scOMH/WtDmL/ SsxBh2QpvXr8qN7vUjWsuvyZg8bCvfUzCU06EOdhNks5pav3NCoN2wDpgXepSFDFWoJh 8gCeRcS9v75oR4dEJJeo6B0GAHI6EUGSyxBzaS1PBsydIbR84FKq3cCjokSPygKkHr3b DoJiHIvWanhxYmJRFwaglGt55RhnE69wEJocNsqgwWlBFy7k6z/n2lV6xFjGI2JJQole GCsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=l+d0OGtRtkY09M0VLBofFywNSItSfbSemC3EkYMtQyY=; b=DJ61OosgAA9Xu1zg5jbPd/MgGoR9m0T3cFJQcWhCtDItMU7fkSv65wmaOYqyw9JiMU 2KDCq+Gkpt9uyWaUrk4tjQMOyqIDW/NMG0v0nu5OhTV+cmnWjb5ThxVw1mLTYCYwxvBE 4TNynxpaLtiqO0z6jSRxloqIirbRae2B7nnSL4UGtRNVp+Bjhsue/nREAFafTwPetzkJ k+3gwQ5SZZ6DKq1mBwijTXD28ku1wJpAngin7fbk02Lkzr93kEInjzwrp6f6AJESn3iV 31rrfNZtVZiM9/TKwHXTqQhLJDCD6i/V0PMlIN3Y9b604ArSIUVMGRjM/7Dmb/q/ZSdX 3b5Q== X-Gm-Message-State: AJIora/mrT69uaPfDIYAzHm48jp/3NUEQFG2F9v7VfIVuZ3RFjfVgKom 6/e8XvUTj6JftV0zUZzUXQ== X-Google-Smtp-Source: AGRyM1sCQntLUzCfsXoFtqsZy7Xh7dUH0cStwNLtXgYEfOK9ftLkc8zvJEC5P2/PdCc5Fs8haLDBMg== X-Received: by 2002:a05:6a00:134f:b0:51c:4c92:1dae with SMTP id k15-20020a056a00134f00b0051c4c921daemr43342643pfu.32.1656028354057; Thu, 23 Jun 2022 16:52:34 -0700 (PDT) Received: from ik1-406-35019.vs.sakura.ne.jp (ik1-406-35019.vs.sakura.ne.jp. [153.127.16.23]) by smtp.gmail.com with ESMTPSA id r10-20020a170903020a00b00168eab11f67sm362571plh.94.2022.06.23.16.52.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jun 2022 16:52:33 -0700 (PDT) From: Naoya Horiguchi X-Google-Original-From: Naoya Horiguchi To: linux-mm@kvack.org Cc: Andrew Morton , David Hildenbrand , Mike Kravetz , Miaohe Lin , Liu Shixin , Yang Shi , Oscar Salvador , Muchun Song , Naoya Horiguchi , linux-kernel@vger.kernel.org Subject: [PATCH v2 2/9] mm/hugetlb: separate path for hwpoison entry in copy_hugetlb_page_range() Date: Fri, 24 Jun 2022 08:51:46 +0900 Message-Id: <20220623235153.2623702-3-naoya.horiguchi@linux.dev> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220623235153.2623702-1-naoya.horiguchi@linux.dev> References: <20220623235153.2623702-1-naoya.horiguchi@linux.dev> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Naoya Horiguchi Originally copy_hugetlb_page_range() handles migration entries and hwpoisone entries in similar manner. But recently the related code path has more code for migration entries, and when is_writable_migration_entry() was converted to !is_readable_migration_entry(), hwpoison entries on source processes got to be unexpectedly updated (which is legitimate for migration entries, but not for hwpoison entries). This results in unexpected serious issues like kernel panic when foking processes with hwpoison entries in pmd. Separate the if branch into one for hwpoison entries and one for migration entries. Fixes: 6c287605fd56 ("mm: remember exclusively mapped anonymous pages with = PG_anon_exclusive") Signed-off-by: Naoya Horiguchi Cc: # 5.18 Reviewed-by: Miaohe Lin Reviewed-by: Mike Kravetz Reviewed-by: Muchun Song --- mm/hugetlb.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index c538278170a2..f59f43c06601 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -4784,8 +4784,13 @@ int copy_hugetlb_page_range(struct mm_struct *dst, s= truct mm_struct *src, * sharing with another vma. */ ; - } else if (unlikely(is_hugetlb_entry_migration(entry) || - is_hugetlb_entry_hwpoisoned(entry))) { + } else if (unlikely(is_hugetlb_entry_hwpoisoned(entry))) { + bool uffd_wp =3D huge_pte_uffd_wp(entry); + + if (!userfaultfd_wp(dst_vma) && uffd_wp) + entry =3D huge_pte_clear_uffd_wp(entry); + set_huge_swap_pte_at(dst, addr, dst_pte, entry, sz); + } else if (unlikely(is_hugetlb_entry_migration(entry))) { swp_entry_t swp_entry =3D pte_to_swp_entry(entry); bool uffd_wp =3D huge_pte_uffd_wp(entry); =20 --=20 2.25.1 From nobody Mon Apr 20 01:09:47 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0A322C433EF for ; Thu, 23 Jun 2022 23:52:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231219AbiFWXwk (ORCPT ); Thu, 23 Jun 2022 19:52:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56614 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231199AbiFWXwi (ORCPT ); Thu, 23 Jun 2022 19:52:38 -0400 Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C00B060C47 for ; Thu, 23 Jun 2022 16:52:37 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id m14so621330plg.5 for ; Thu, 23 Jun 2022 16:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=gLXI0bFmtdpL1fm2aZ9vhvRpJm3p+mQNTKIlYsIrOjU=; b=n3EpWNne89DpkqcHeRXrJ15yy+IykIai7ornumZPTFP3oBklmi1A9IfZR2B/qtHRBE fEhmAFan4uUC7OrYWIDjV7OSRH6ALcWMbKnDZSnGBAIPyEKvGE2GD8iLzFiQWbhjOx8P IFNuSd9GajJZepS7jAVhRX8+KQZnAlpgD4YGn66q6n+VtWWRkfFQljjadM7UsZJhdNcu W5am1TruDf29uTRDkrxWzSbMs3OV9pweR6PMVYdkYTxMG98IlJmK7MRM3Pe2tLTOpxMP w9fq/O2WZelM6ft+W/kTXDjoHIMwggETk7IWGuE//bekvG8z5qhjUlCrGxuudfCbY2gV /lcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=gLXI0bFmtdpL1fm2aZ9vhvRpJm3p+mQNTKIlYsIrOjU=; b=wURwaRGzHKOQr/n48YjdU260iq3jESUwQi5hO4l3PLWCY9nEuoKxkk8vYiNY8/dQF7 MG2qbDtbcXLx9ADYheIUQqbp1yVLzA5LdxsC2rglP4qcqmpVQOoq8mu8r5rrAC6PT/fu Iwr1bTtFH8gTnPQ9whsYoWEw91SOD6BjFsox6UGdrk+hZOEP6PPWMLNNSho864R1gnwk oDE1BNqHwkZz6MB/b9k7im1T8mkam17Qoh6VfP1QGjGms2cIjOP2IEk7FF7V/o+Q1lQm GZpl7IvenaX5xP94IG1cumeWi83Pejq3NXMiJsTE+gadxSOaYQM0Q4KT3vt61OGAWIn4 WHug== X-Gm-Message-State: AJIora9OcV7y0fJtaDGul3F1FVPWCYJGUkm/myv+CIUHlpiXkwotI6U0 3HkpDYsPBMUo9BDevOJWXg== X-Google-Smtp-Source: AGRyM1swwZN4zwkDXsQnlRX7chaljh2k4qwXaQviyOxNxdAje8fNl06jiLeDO1ZeRVZ07VAF4OC9+g== X-Received: by 2002:a17:903:2350:b0:16a:4246:f1b6 with SMTP id c16-20020a170903235000b0016a4246f1b6mr12420841plh.35.1656028357207; Thu, 23 Jun 2022 16:52:37 -0700 (PDT) Received: from ik1-406-35019.vs.sakura.ne.jp (ik1-406-35019.vs.sakura.ne.jp. [153.127.16.23]) by smtp.gmail.com with ESMTPSA id r10-20020a170903020a00b00168eab11f67sm362571plh.94.2022.06.23.16.52.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jun 2022 16:52:36 -0700 (PDT) From: Naoya Horiguchi X-Google-Original-From: Naoya Horiguchi To: linux-mm@kvack.org Cc: Andrew Morton , David Hildenbrand , Mike Kravetz , Miaohe Lin , Liu Shixin , Yang Shi , Oscar Salvador , Muchun Song , Naoya Horiguchi , linux-kernel@vger.kernel.org Subject: [PATCH v2 3/9] mm/hugetlb: make pud_huge() and huge_pud() aware of non-present pud entry Date: Fri, 24 Jun 2022 08:51:47 +0900 Message-Id: <20220623235153.2623702-4-naoya.horiguchi@linux.dev> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220623235153.2623702-1-naoya.horiguchi@linux.dev> References: <20220623235153.2623702-1-naoya.horiguchi@linux.dev> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Naoya Horiguchi follow_pud_mask() does not support non-present pud entry now. As long as I tested on x86_64 server, follow_pud_mask() still simply returns no_page_table() for non-present_pud_entry() due to pud_bad(), so no severe user-visible effect should happen. But generally we should call follow_huge_pud() for non-present pud entry for 1GB hugetlb page. Update pud_huge() and huge_pud() to handle non-present pud entries. The changes are similar to previous works for pud entries commit e66f17ff7177 ("mm/hugetlb: take page table lock in follow_huge_pmd()") and commit cbef8478bee5 ("mm/hugetlb: pmd_huge() returns true for non-present hugepage= "). Signed-off-by: Naoya Horiguchi --- arch/x86/mm/hugetlbpage.c | 3 ++- mm/hugetlb.c | 26 +++++++++++++++++++++++++- 2 files changed, 27 insertions(+), 2 deletions(-) diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c index a0d023cb4292..5fb86fb49ba8 100644 --- a/arch/x86/mm/hugetlbpage.c +++ b/arch/x86/mm/hugetlbpage.c @@ -70,7 +70,8 @@ int pmd_huge(pmd_t pmd) =20 int pud_huge(pud_t pud) { - return !!(pud_val(pud) & _PAGE_PSE); + return !pud_none(pud) && + (pud_val(pud) & (_PAGE_PRESENT|_PAGE_PSE)) !=3D _PAGE_PRESENT; } #endif =20 diff --git a/mm/hugetlb.c b/mm/hugetlb.c index f59f43c06601..b7ae5f73f3b2 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -6946,10 +6946,34 @@ struct page * __weak follow_huge_pud(struct mm_struct *mm, unsigned long address, pud_t *pud, int flags) { + struct page *page =3D NULL; + spinlock_t *ptl; + pte_t pte; + if (flags & (FOLL_GET | FOLL_PIN)) return NULL; =20 - return pte_page(*(pte_t *)pud) + ((address & ~PUD_MASK) >> PAGE_SHIFT); +retry: + ptl =3D huge_pte_lock(hstate_sizelog(PUD_SHIFT), mm, (pte_t *)pud); + if (!pud_huge(*pud)) + goto out; + pte =3D huge_ptep_get((pte_t *)pud); + if (pte_present(pte)) { + page =3D pud_page(*pud) + ((address & ~PUD_MASK) >> PAGE_SHIFT); + if (WARN_ON_ONCE(!try_grab_page(page, flags))) { + page =3D NULL; + goto out; + } + } else { + if (is_hugetlb_entry_migration(pte)) { + spin_unlock(ptl); + __migration_entry_wait(mm, (pte_t *)pud, ptl); + goto retry; + } + } +out: + spin_unlock(ptl); + return page; } =20 struct page * __weak --=20 2.25.1 From nobody Mon Apr 20 01:09:47 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B05ACC43334 for ; Thu, 23 Jun 2022 23:52:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231248AbiFWXwq (ORCPT ); Thu, 23 Jun 2022 19:52:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56648 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231222AbiFWXwl (ORCPT ); Thu, 23 Jun 2022 19:52:41 -0400 Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DD03860C46 for ; Thu, 23 Jun 2022 16:52:40 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id h9-20020a17090a648900b001ecb8596e43so1147430pjj.5 for ; Thu, 23 Jun 2022 16:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=TAJYwYrd1tyojXaywF9IiUbYLQjEtu9FiUYYeWzF2Rw=; b=JeyytKAAkynnoiRRZ20ZhrJ8TRPHzLJyJkx/Jq//4aqdCxJhvcNvrEhL8eZxORpykD VfSuX/slc2Ow7ch6vlL5mPA4RAiwka4tR58+U/vdGSvfTJBsrseDamxhzL+KUgw/ckER aSLeIn1FWF3zIFKFytgoAkHWEL2TFzH5pA0CrWAmPOvjfRgA5Zayz/WioK5ADPF4lb5z Z6LpXej3Nn6tM3Vc7jG/GfmqEBBJHsr0FD/aliT8s0MshxIMI7gegBsXSja0MmR5lDzd R/cQT8tLU31XqinTg5uY/ZLNUIf4ltCU7MX4e2EH8RWQMHDEHZ1AZRkIojs/odgQwM5X z/rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=TAJYwYrd1tyojXaywF9IiUbYLQjEtu9FiUYYeWzF2Rw=; b=v955iy1T0ggmd2N54XEvU6esTV6awO2lt8MxImnE6QOQedm9qkKem+JVam5NW1gluQ yjlKxEFmLotDK4Whus+slyHs3wNdEhwGeHRoD47fsZ1WE7kQWRhA0lyovV2Tpu1U0l9Y W3lJIIPT4KKEP43UO2t54kEJWRo2a574sABenvAUtIjjmyAHB2pZWw4z9WnOjXERGzQT 96cq23YDDKjQjjhXg5I9pu06E2te8rtsqvcp6P7LWVP94gbb/XQ5ZTx3v1gT8TzTIhcn VXBsaDxEi5BxYWHlHM4hBpNQKKBPxKhaZr+PRxokoOpTX/gONWX+3VsB0l7DGzsBjdPg Pwgw== X-Gm-Message-State: AJIora8JxoflUOf5i/coNoN84l70Lgwlkb9Lnu5Ygj/tnjjQx33DzJ+H tI93cG2trdmMD98hVgaDBw== X-Google-Smtp-Source: AGRyM1s8Qo2wZLu117yPTVjGPSDeSHkvrMoIz0nMpNtrh4bomIN/aKXR67bO9Nr5UDZnTcjQXHxSPw== X-Received: by 2002:a17:90b:1c87:b0:1ca:f4e:4fbe with SMTP id oo7-20020a17090b1c8700b001ca0f4e4fbemr540195pjb.159.1656028360332; Thu, 23 Jun 2022 16:52:40 -0700 (PDT) Received: from ik1-406-35019.vs.sakura.ne.jp (ik1-406-35019.vs.sakura.ne.jp. [153.127.16.23]) by smtp.gmail.com with ESMTPSA id r10-20020a170903020a00b00168eab11f67sm362571plh.94.2022.06.23.16.52.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jun 2022 16:52:40 -0700 (PDT) From: Naoya Horiguchi X-Google-Original-From: Naoya Horiguchi To: linux-mm@kvack.org Cc: Andrew Morton , David Hildenbrand , Mike Kravetz , Miaohe Lin , Liu Shixin , Yang Shi , Oscar Salvador , Muchun Song , Naoya Horiguchi , linux-kernel@vger.kernel.org Subject: [PATCH v2 4/9] mm, hwpoison, hugetlb: support saving mechanism of raw error pages Date: Fri, 24 Jun 2022 08:51:48 +0900 Message-Id: <20220623235153.2623702-5-naoya.horiguchi@linux.dev> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220623235153.2623702-1-naoya.horiguchi@linux.dev> References: <20220623235153.2623702-1-naoya.horiguchi@linux.dev> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Naoya Horiguchi When handling memory error on a hugetlb page, the error handler tries to dissolve and turn it into 4kB pages. If it's successfully dissolved, PageHWPoison flag is moved to the raw error page, so that's all right. However, dissolve sometimes fails, then the error page is left as hwpoisoned hugepage. It's useful if we can retry to dissolve it to save healthy pages, but that's not possible now because the information about where the raw error pages is lost. Use the private field of a few tail pages to keep that information. The code path of shrinking hugepage pool uses this info to try delayed dissolve. In order to remember multiple errors in a hugepage, a singly-linked list originated from SUBPAGE_INDEX_HWPOISON-th tail page is constructed. Only simple operations (adding an entry or clearing all) are required and the list is assumed not to be very long, so this simple data structure should be enough. If we failed to save raw error info, the hwpoison hugepage has errors on unknown subpage, then this new saving mechanism does not work any more, so disable saving new raw error info and freeing hwpoison hugepages. Signed-off-by: Naoya Horiguchi --- v1 -> v2: - support hwpoison hugepage with multiple errors, - moved the new interface functions to mm/memory-failure.c, - define additional subpage index SUBPAGE_INDEX_HWPOISON_UNRELIABLE, - stop freeing/dissolving hwpoison hugepages with unreliable raw error info, - drop hugetlb_clear_page_hwpoison() in dissolve_free_huge_page() because that's done in update_and_free_page(), - move setting/clearing PG_hwpoison flag to the new interfaces, - checking already hwpoisoned or not on a subpage basis. ChangeLog since previous post on 4/27: - fixed typo in patch description (by Miaohe) - fixed config value in #ifdef statement (by Miaohe) - added sentences about "multiple hwpoison pages" scenario in patch description Signed-off-by: Naoya Horiguchi --- include/linux/hugetlb.h | 13 ++++++ mm/hugetlb.c | 39 +++++++++-------- mm/memory-failure.c | 95 ++++++++++++++++++++++++++++++++++++++++- 3 files changed, 125 insertions(+), 22 deletions(-) diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index e4cff27d1198..ac13c2022517 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -42,6 +42,10 @@ enum { SUBPAGE_INDEX_CGROUP, /* reuse page->private */ SUBPAGE_INDEX_CGROUP_RSVD, /* reuse page->private */ __MAX_CGROUP_SUBPAGE_INDEX =3D SUBPAGE_INDEX_CGROUP_RSVD, +#endif +#ifdef CONFIG_MEMORY_FAILURE + SUBPAGE_INDEX_HWPOISON, + SUBPAGE_INDEX_HWPOISON_UNRELIABLE, #endif __NR_USED_SUBPAGE, }; @@ -798,6 +802,15 @@ extern int dissolve_free_huge_page(struct page *page); extern int dissolve_free_huge_pages(unsigned long start_pfn, unsigned long end_pfn); =20 +#ifdef CONFIG_MEMORY_FAILURE +extern int hugetlb_clear_page_hwpoison(struct page *hpage); +#else +static inline int hugetlb_clear_page_hwpoison(struct page *hpage) +{ + return 0; +} +#endif + #ifdef CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION #ifndef arch_hugetlb_migration_supported static inline bool arch_hugetlb_migration_supported(struct hstate *h) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index b7ae5f73f3b2..19ef427aa1e8 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -1541,17 +1541,15 @@ static void __update_and_free_page(struct hstate *h= , struct page *page) if (hstate_is_gigantic(h) && !gigantic_page_runtime_supported()) return; =20 - if (hugetlb_vmemmap_alloc(h, page)) { - spin_lock_irq(&hugetlb_lock); - /* - * If we cannot allocate vmemmap pages, just refuse to free the - * page and put the page back on the hugetlb free list and treat - * as a surplus page. - */ - add_hugetlb_page(h, page, true); - spin_unlock_irq(&hugetlb_lock); - return; - } + if (hugetlb_vmemmap_alloc(h, page)) + goto fail; + + /* + * Move PageHWPoison flag from head page to the raw error pages, + * which makes any healthy subpages reusable. + */ + if (unlikely(PageHWPoison(page) && hugetlb_clear_page_hwpoison(page))) + goto fail; =20 for (i =3D 0; i < pages_per_huge_page(h); i++, subpage =3D mem_map_next(subpage, page, i)) { @@ -1572,6 +1570,16 @@ static void __update_and_free_page(struct hstate *h,= struct page *page) } else { __free_pages(page, huge_page_order(h)); } + return; +fail: + spin_lock_irq(&hugetlb_lock); + /* + * If we cannot allocate vmemmap pages or cannot identify raw hwpoison + * subpages reliably, just refuse to free the page and put the page + * back on the hugetlb free list and treat as a surplus page. + */ + add_hugetlb_page(h, page, true); + spin_unlock_irq(&hugetlb_lock); } =20 /* @@ -2115,15 +2123,6 @@ int dissolve_free_huge_page(struct page *page) */ rc =3D hugetlb_vmemmap_alloc(h, head); if (!rc) { - /* - * Move PageHWPoison flag from head page to the raw - * error page, which makes any subpages rather than - * the error page reusable. - */ - if (PageHWPoison(head) && page !=3D head) { - SetPageHWPoison(page); - ClearPageHWPoison(head); - } update_and_free_page(h, head, false); } else { spin_lock_irq(&hugetlb_lock); diff --git a/mm/memory-failure.c b/mm/memory-failure.c index fb3feb1f363e..af571fa6f2af 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -1499,6 +1499,97 @@ static int try_to_split_thp_page(struct page *page, = const char *msg) } =20 #ifdef CONFIG_HUGETLB_PAGE +/* + * Struct raw_hwp_page represents information about "raw error page", + * constructing singly linked list originated from ->private field of + * SUBPAGE_INDEX_HWPOISON-th tail page. + */ +struct raw_hwp_page { + struct llist_node node; + struct page *page; +}; + +static inline struct llist_head *raw_hwp_list_head(struct page *hpage) +{ + return (struct llist_head *)&page_private(hpage + SUBPAGE_INDEX_HWPOISON); +} + +static inline int raw_hwp_unreliable(struct page *hpage) +{ + return page_private(hpage + SUBPAGE_INDEX_HWPOISON_UNRELIABLE); +} + +static inline void set_raw_hwp_unreliable(struct page *hpage) +{ + set_page_private(hpage + SUBPAGE_INDEX_HWPOISON_UNRELIABLE, 1); +} + +/* + * about race consideration + */ +static inline int hugetlb_set_page_hwpoison(struct page *hpage, + struct page *page) +{ + struct llist_head *head; + struct raw_hwp_page *raw_hwp; + struct llist_node *t, *tnode; + int ret; + + /* + * Once the hwpoison hugepage has lost reliable raw error info, + * there is little mean to keep additional error info precisely, + * so skip to add additional raw error info. + */ + if (raw_hwp_unreliable(hpage)) + return -EHWPOISON; + head =3D raw_hwp_list_head(hpage); + llist_for_each_safe(tnode, t, head->first) { + struct raw_hwp_page *p =3D container_of(tnode, struct raw_hwp_page, node= ); + + if (p->page =3D=3D page) + return -EHWPOISON; + } + + ret =3D TestSetPageHWPoison(hpage) ? -EHWPOISON : 0; + /* the first error event will be counted in action_result(). */ + if (ret) + num_poisoned_pages_inc(); + + raw_hwp =3D kmalloc(sizeof(struct raw_hwp_page), GFP_KERNEL); + if (raw_hwp) { + raw_hwp->page =3D page; + llist_add(&raw_hwp->node, head); + } else { + /* + * Failed to save raw error info. We no longer trace all + * hwpoisoned subpages, and we need refuse to free/dissolve + * this hwpoisoned hugepage. + */ + set_raw_hwp_unreliable(hpage); + return ret; + } + return ret; +} + +inline int hugetlb_clear_page_hwpoison(struct page *hpage) +{ + struct llist_head *head; + struct llist_node *t, *tnode; + + if (raw_hwp_unreliable(hpage)) + return -EBUSY; + ClearPageHWPoison(hpage); + head =3D raw_hwp_list_head(hpage); + llist_for_each_safe(tnode, t, head->first) { + struct raw_hwp_page *p =3D container_of(tnode, struct raw_hwp_page, node= ); + + SetPageHWPoison(p->page); + kfree(p); + } + llist_del_all(head); + return 0; +} + /* * Called from hugetlb code with hugetlb_lock held. * @@ -1533,7 +1624,7 @@ int __get_huge_page_for_hwpoison(unsigned long pfn, i= nt flags) goto out; } =20 - if (TestSetPageHWPoison(head)) { + if (hugetlb_set_page_hwpoison(head, page)) { ret =3D -EHWPOISON; goto out; } @@ -1585,7 +1676,7 @@ static int try_memory_failure_hugetlb(unsigned long p= fn, int flags, int *hugetlb lock_page(head); =20 if (hwpoison_filter(p)) { - ClearPageHWPoison(head); + hugetlb_clear_page_hwpoison(head); res =3D -EOPNOTSUPP; goto out; } --=20 2.25.1 From nobody Mon Apr 20 01:09:47 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 030C7C43334 for ; Thu, 23 Jun 2022 23:52:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231253AbiFWXwz (ORCPT ); Thu, 23 Jun 2022 19:52:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56726 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231244AbiFWXwq (ORCPT ); Thu, 23 Jun 2022 19:52:46 -0400 Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EB8D660C4A for ; Thu, 23 Jun 2022 16:52:43 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id k7so614310plg.7 for ; Thu, 23 Jun 2022 16:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=9qDM1SEwhJHNMkiAW+9hnn1MZNaGCub7B2p3sdAevGo=; b=a7P7HnrlqqsSBAv8Rh9l5P0qKEPodg3DsKsYr1Ea4M2Kn+QsYmKyxzF6uMI7LIyD90 D7dQ6KAxhdboYEDc65+ew8MRy8m7dAcgAw/XN9mFluukHhigzZK9AlkGJoXVhUYCDYxB iLNdAr+Lt1+Hhj13KaJVx531dr/ndkA5+wn+Xx0ZMBms/VzRGeN93f23HV3Fivmq0x4S wekPTJ7XFlXQdG1L1/GEkg4Y9ZXaUdt5cHqskGHTeZ1REkKnnlA7yUZkP2sRj28BTcsr 1SpvYWYgizD/bL6oe+cCC39Of/ccsD5GQvut0an6oon8bsbqSxFnCig0gv8wbdTZOacr re2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=9qDM1SEwhJHNMkiAW+9hnn1MZNaGCub7B2p3sdAevGo=; b=PNB7tLOviX0eLEO3z3r1y/eF/J+V99W4opgSBf2g1aKscUlf4sDq5ISFPI1RWGt928 xl7GL1bWDqDfkILLkHgHckWMaN2c2AxtBwTZdbpBX8UatXd7AmUmMYO0bU76jKXCj5tf t+qNHf+XRafsa4ogRz2Fd8kpkXVCgDlLHDqOO0OqntDHg5DNhUF1nNRFnwbLESiKoyp2 G2HGJFsIoIlpd8Zd8b4+ppvfGXWJQneXfTc9R7nH40mH0AlMtuY3UK+qGgB5e4pCUBkl 4kI0MAgUJbb/e+9vmbpR5Ok43y2J0UUcPvqwhCb1nKeH8DmxEC2+Rw9+sLHp1VRHojp/ dAOw== X-Gm-Message-State: AJIora/zp1h33FDvTa6SPYK4tE1O9krUE35cjTLyB4xIe/zL3QOyojnU 9ih/dboIabZ9PDkdbSVwUCQYa5m1sg== X-Google-Smtp-Source: AGRyM1to5MI42NBV7wBN2fu1N3JmUZLbmtHx8xzIu63b/rMAvK85lhxS+WOmvPyJdXJd+RprgZCMnw== X-Received: by 2002:a17:90a:1588:b0:1e0:a45c:5c1 with SMTP id m8-20020a17090a158800b001e0a45c05c1mr550853pja.65.1656028363425; Thu, 23 Jun 2022 16:52:43 -0700 (PDT) Received: from ik1-406-35019.vs.sakura.ne.jp (ik1-406-35019.vs.sakura.ne.jp. [153.127.16.23]) by smtp.gmail.com with ESMTPSA id r10-20020a170903020a00b00168eab11f67sm362571plh.94.2022.06.23.16.52.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jun 2022 16:52:43 -0700 (PDT) From: Naoya Horiguchi X-Google-Original-From: Naoya Horiguchi To: linux-mm@kvack.org Cc: Andrew Morton , David Hildenbrand , Mike Kravetz , Miaohe Lin , Liu Shixin , Yang Shi , Oscar Salvador , Muchun Song , Naoya Horiguchi , linux-kernel@vger.kernel.org Subject: [PATCH v2 5/9] mm, hwpoison: make unpoison aware of raw error info in hwpoisoned hugepage Date: Fri, 24 Jun 2022 08:51:49 +0900 Message-Id: <20220623235153.2623702-6-naoya.horiguchi@linux.dev> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220623235153.2623702-1-naoya.horiguchi@linux.dev> References: <20220623235153.2623702-1-naoya.horiguchi@linux.dev> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Naoya Horiguchi Raw error info list needs to be removed when hwpoisoned hugetlb is unpoisioned. And unpoison handler needs to know how many errors there are in the target hugepage. So add them. Signed-off-by: Naoya Horiguchi --- include/linux/swapops.h | 9 +++++++++ mm/memory-failure.c | 34 +++++++++++++++++++++++++++------- 2 files changed, 36 insertions(+), 7 deletions(-) diff --git a/include/linux/swapops.h b/include/linux/swapops.h index 9584c2e1c54a..ad62776ee99c 100644 --- a/include/linux/swapops.h +++ b/include/linux/swapops.h @@ -494,6 +494,11 @@ static inline void num_poisoned_pages_dec(void) atomic_long_dec(&num_poisoned_pages); } =20 +static inline void num_poisoned_pages_sub(long i) +{ + atomic_long_sub(i, &num_poisoned_pages); +} + #else =20 static inline swp_entry_t make_hwpoison_entry(struct page *page) @@ -514,6 +519,10 @@ static inline struct page *hwpoison_entry_to_page(swp_= entry_t entry) static inline void num_poisoned_pages_inc(void) { } + +static inline void num_poisoned_pages_sub(long i) +{ +} #endif =20 static inline int non_swap_entry(swp_entry_t entry) diff --git a/mm/memory-failure.c b/mm/memory-failure.c index af571fa6f2af..6005e953d011 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -1571,23 +1571,34 @@ static inline int hugetlb_set_page_hwpoison(struct = page *hpage, return ret; } =20 -inline int hugetlb_clear_page_hwpoison(struct page *hpage) +static inline long free_raw_hwp_pages(struct page *hpage, bool move_flag) { struct llist_head *head; struct llist_node *t, *tnode; + long count =3D 0; =20 - if (raw_hwp_unreliable(hpage)) - return -EBUSY; - ClearPageHWPoison(hpage); head =3D raw_hwp_list_head(hpage); llist_for_each_safe(tnode, t, head->first) { struct raw_hwp_page *p =3D container_of(tnode, struct raw_hwp_page, node= ); =20 - SetPageHWPoison(p->page); + if (move_flag) + SetPageHWPoison(p->page); kfree(p); + count++; } llist_del_all(head); - return 0; + return count; +} + +inline int hugetlb_clear_page_hwpoison(struct page *hpage) +{ + int ret =3D -EBUSY; + + if (raw_hwp_unreliable(hpage)) + return ret; + ret =3D !TestClearPageHWPoison(hpage); + free_raw_hwp_pages(hpage, true); + return ret; } =20 /* @@ -1729,6 +1740,10 @@ static inline int try_memory_failure_hugetlb(unsigne= d long pfn, int flags, int * { return 0; } + +static inline void free_raw_hwp_pages(struct page *hpage, bool move_flag) +{ +} #endif =20 static int memory_failure_dev_pagemap(unsigned long pfn, int flags, @@ -2188,6 +2203,7 @@ int unpoison_memory(unsigned long pfn) struct page *p; int ret =3D -EBUSY; int freeit =3D 0; + long count =3D 1; static DEFINE_RATELIMIT_STATE(unpoison_rs, DEFAULT_RATELIMIT_INTERVAL, DEFAULT_RATELIMIT_BURST); =20 @@ -2235,6 +2251,8 @@ int unpoison_memory(unsigned long pfn) =20 ret =3D get_hwpoison_page(p, MF_UNPOISON); if (!ret) { + if (PageHuge(p)) + count =3D free_raw_hwp_pages(page, false); ret =3D TestClearPageHWPoison(page) ? 0 : -EBUSY; } else if (ret < 0) { if (ret =3D=3D -EHWPOISON) { @@ -2243,6 +2261,8 @@ int unpoison_memory(unsigned long pfn) unpoison_pr_info("Unpoison: failed to grab page %#lx\n", pfn, &unpoison_rs); } else { + if (PageHuge(p)) + count =3D free_raw_hwp_pages(page, false); freeit =3D !!TestClearPageHWPoison(p); =20 put_page(page); @@ -2255,7 +2275,7 @@ int unpoison_memory(unsigned long pfn) unlock_mutex: mutex_unlock(&mf_mutex); if (!ret || freeit) { - num_poisoned_pages_dec(); + num_poisoned_pages_sub(count); unpoison_pr_info("Unpoison: Software-unpoisoned page %#lx\n", page_to_pfn(p), &unpoison_rs); } --=20 2.25.1 From nobody Mon Apr 20 01:09:47 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 88006C43334 for ; Thu, 23 Jun 2022 23:53:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231284AbiFWXw7 (ORCPT ); Thu, 23 Jun 2022 19:52:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56998 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231254AbiFWXwx (ORCPT ); Thu, 23 Jun 2022 19:52:53 -0400 Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 03DA560C53 for ; Thu, 23 Jun 2022 16:52:47 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id n10so665774plp.0 for ; Thu, 23 Jun 2022 16:52:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=KvUi4xXUaw0Gsdez/sII2VYp9q4T8l1odrgep5/r9aE=; b=b71HZZHM2aY5ylc8U6Uu7sxHM5Q4Dz7cL/mOReiZJuAaeu2rHNu+hnQmQAv38dDmwP pOKIk5yY/X85zQfa1Ys2n7GhIPD0SVPxsFL/z9/OGvRegbXwb/U4EHvDpjg7cQ1S0pyP KWtLwypFgkCY/db06rZ/D2urozJab3xD2VJxRbQ0no53NC4CzSsNbu/G6NHqRh9A8X+F 8OTJbDheCebOpKua3A0uEj2qHKjRhFb2+wCy2g910KB5HQ2VrIMCFd/2r8H0V9axz7PU b2cZtNIaDaxWhsGU+tHFIrLWR/bKzQEwuNlwc7ldCcwha2zy4xep6e7bfU6vHKhpsNqV 7Cvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=KvUi4xXUaw0Gsdez/sII2VYp9q4T8l1odrgep5/r9aE=; b=TerCug24D2xvDqJwPbU2RgOjVJB7OTQYBeUTA+4BlBNUU+GOrf+/xfH8lsV1Df7I7r nEKSnyCPsvX3RMCCGVvM8xiy2c/Fj0ijvTtQg5hErVM2SqX3bqvwPxwSI1ZXhcxQIS9P xAlHnogjX6rXeHp288kcFZxResHFqutCGUchhBMtWIRfMH4lZdRgNayi7lO8Uvv24s3D 8TBCebLz4zXw6zPRGKF1OGTVQr15qOoFgy+2M9G2rGUnO2dCyNZ+RmhIIhZXIKbShbr6 BvllU+u6AzZqS0lxhb9GQ+PlP013VL7w+EDNHfNhM/jQz0vwYBXtr0zpjW5ce7mgkt9y FZEw== X-Gm-Message-State: AJIora/C+3qi/AYzmlb5C7iBhmclkx4Qpl++t60WgqlkBowCEFd7TEFB msJ5XyUqGXlxB2OVMl0SwA== X-Google-Smtp-Source: AGRyM1u3RWXKYbvMbZlXJV9HgWdbCWIpY9vHZiP0MBdnlmG8yhoNWv12HEJym6YydHWar1VwhEIpYw== X-Received: by 2002:a17:902:ebc1:b0:168:fd13:8adc with SMTP id p1-20020a170902ebc100b00168fd138adcmr41512651plg.161.1656028366487; Thu, 23 Jun 2022 16:52:46 -0700 (PDT) Received: from ik1-406-35019.vs.sakura.ne.jp (ik1-406-35019.vs.sakura.ne.jp. [153.127.16.23]) by smtp.gmail.com with ESMTPSA id r10-20020a170903020a00b00168eab11f67sm362571plh.94.2022.06.23.16.52.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jun 2022 16:52:46 -0700 (PDT) From: Naoya Horiguchi X-Google-Original-From: Naoya Horiguchi To: linux-mm@kvack.org Cc: Andrew Morton , David Hildenbrand , Mike Kravetz , Miaohe Lin , Liu Shixin , Yang Shi , Oscar Salvador , Muchun Song , Naoya Horiguchi , linux-kernel@vger.kernel.org Subject: [PATCH v2 6/9] mm, hwpoison: set PG_hwpoison for busy hugetlb pages Date: Fri, 24 Jun 2022 08:51:50 +0900 Message-Id: <20220623235153.2623702-7-naoya.horiguchi@linux.dev> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220623235153.2623702-1-naoya.horiguchi@linux.dev> References: <20220623235153.2623702-1-naoya.horiguchi@linux.dev> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Naoya Horiguchi If memory_failure() fails to grab page refcount on a hugetlb page because it's busy, it returns without setting PG_hwpoison on it. This not only loses a chance of error containment, but breaks the rule that action_result() should be called only when memory_failure() do any of handling work (even if that's just setting PG_hwpoison). This inconsistency could harm code maintainability. So set PG_hwpoison and call hugetlb_set_page_hwpoison() for such a case. Fixes: 405ce051236c ("mm/hwpoison: fix race between hugetlb free/demotion a= nd memory_failure_hugetlb()") Signed-off-by: Naoya Horiguchi Reviewed-by: Miaohe Lin --- include/linux/mm.h | 1 + mm/memory-failure.c | 8 ++++---- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index 4346e51484ba..044dc5a2e361 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -3233,6 +3233,7 @@ enum mf_flags { MF_SOFT_OFFLINE =3D 1 << 3, MF_UNPOISON =3D 1 << 4, MF_SW_SIMULATED =3D 1 << 5, + MF_NO_RETRY =3D 1 << 6, }; extern int memory_failure(unsigned long pfn, int flags); extern void memory_failure_queue(unsigned long pfn, int flags); diff --git a/mm/memory-failure.c b/mm/memory-failure.c index 6005e953d011..ce045d0d6115 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -1632,7 +1632,8 @@ int __get_huge_page_for_hwpoison(unsigned long pfn, i= nt flags) count_increased =3D true; } else { ret =3D -EBUSY; - goto out; + if (!(flags & MF_NO_RETRY)) + goto out; } =20 if (hugetlb_set_page_hwpoison(head, page)) { @@ -1659,7 +1660,6 @@ static int try_memory_failure_hugetlb(unsigned long p= fn, int flags, int *hugetlb struct page *p =3D pfn_to_page(pfn); struct page *head; unsigned long page_flags; - bool retry =3D true; =20 *hugetlb =3D 1; retry: @@ -1675,8 +1675,8 @@ static int try_memory_failure_hugetlb(unsigned long p= fn, int flags, int *hugetlb } return res; } else if (res =3D=3D -EBUSY) { - if (retry) { - retry =3D false; + if (!(flags & MF_NO_RETRY)) { + flags |=3D MF_NO_RETRY; goto retry; } action_result(pfn, MF_MSG_UNKNOWN, MF_IGNORED); --=20 2.25.1 From nobody Mon Apr 20 01:09:47 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 27E52C433EF for ; Thu, 23 Jun 2022 23:53:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231344AbiFWXxF (ORCPT ); Thu, 23 Jun 2022 19:53:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57024 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231265AbiFWXwy (ORCPT ); Thu, 23 Jun 2022 19:52:54 -0400 Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2E18360C5D for ; Thu, 23 Jun 2022 16:52:50 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id p14so1046258pfh.6 for ; Thu, 23 Jun 2022 16:52:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=5pQfND038h5QWcn78qM/I1ai1qmbxoygS2JmZLRC1mQ=; b=iXRbqsMPfof+NUltQHH89pGwAzb42H/dstNMxQgGGt6Yt//W8LgTGOTG0OaoSTeNRz dZWUB59vT4SDDN3iALIsxg16784gK20+rZPhBd+mZNDSqMB9O7U2WxsqjohKmBB6pXUG nibweuhhc5VKaNupCNP0N0YPwZxrsIyX/Bb9vW1e68rAyv5FmPBsYHd9kQFfKyW1Ez5f w5un26afpOlcnOq5acBDDRhfwfXCkdcFPIehGQOKnQhnUuw02P3Yd7V2Oqo0X9yKyjgn RWPTgZnrtjJ7VlJaB/hzIuIdKb1hqY3+8AgAQyB9hZ3NMamUhCbmytLPWpfDRAdW+V2/ eftw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=5pQfND038h5QWcn78qM/I1ai1qmbxoygS2JmZLRC1mQ=; b=4EYLeTeKHX/bMD540LzGlXEce64YbqkipMphbczigDOH9F/OMTR/iYdsR2sdu/6tfJ RFd9VWkXjUhR1vtQkEvIJJbdCHYPgu+mZvysBpnFn9dCbyaJuoTo9NS/ata5TfPNoMW/ CFxZTn+A7BQoyy3aLL2rfsXX+WwYv9Uozp+QzSAoMEsXvPRlmBZJBrXhI9eSFp7geoSH yOluR7paWeZ/KgQOkIdCKjRjy0z/61m7vWL7/wsKzhCshBZbQ0QMe3Kve0FjMdPapnIE T8/UDWbkFfCJrgOHNvMA2S5ElDJva/U61/gibWJNho6lbHZRybopPdfqtW52uVztju2q zwZA== X-Gm-Message-State: AJIora9HVy/1vaCLTdcbAZin1JnFzcngNK8ZkHzVU5sdABqkLtLKMQLE pPIyrMF4Vf1i66wUMI3DIA== X-Google-Smtp-Source: AGRyM1s96G2FFH66JXa8bc7eH4qd+fIDxeMhCkK8flgwP1JhK2XMzt6hxEJTmkotzQNPWlNmHQYnig== X-Received: by 2002:a63:7b5c:0:b0:40d:684:b760 with SMTP id k28-20020a637b5c000000b0040d0684b760mr9535270pgn.323.1656028369640; Thu, 23 Jun 2022 16:52:49 -0700 (PDT) Received: from ik1-406-35019.vs.sakura.ne.jp (ik1-406-35019.vs.sakura.ne.jp. [153.127.16.23]) by smtp.gmail.com with ESMTPSA id r10-20020a170903020a00b00168eab11f67sm362571plh.94.2022.06.23.16.52.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jun 2022 16:52:49 -0700 (PDT) From: Naoya Horiguchi X-Google-Original-From: Naoya Horiguchi To: linux-mm@kvack.org Cc: Andrew Morton , David Hildenbrand , Mike Kravetz , Miaohe Lin , Liu Shixin , Yang Shi , Oscar Salvador , Muchun Song , Naoya Horiguchi , linux-kernel@vger.kernel.org Subject: [PATCH v2 7/9] mm, hwpoison: make __page_handle_poison returns int Date: Fri, 24 Jun 2022 08:51:51 +0900 Message-Id: <20220623235153.2623702-8-naoya.horiguchi@linux.dev> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220623235153.2623702-1-naoya.horiguchi@linux.dev> References: <20220623235153.2623702-1-naoya.horiguchi@linux.dev> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Naoya Horiguchi __page_handle_poison() returns bool that shows whether take_page_off_buddy() has passed or not now. But we will want to distinguish another case of "dissolve has passed but taking off failed" by its return value. So change the type of the return value. No functional change. Signed-off-by: Naoya Horiguchi Reviewed-by: Miaohe Lin --- mm/memory-failure.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/mm/memory-failure.c b/mm/memory-failure.c index ce045d0d6115..db85f644a1e3 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -71,7 +71,13 @@ atomic_long_t num_poisoned_pages __read_mostly =3D ATOMI= C_LONG_INIT(0); =20 static bool hw_memory_failure __read_mostly =3D false; =20 -static bool __page_handle_poison(struct page *page) +/* + * Return values: + * 1: the page is dissolved (if needed) and taken off from buddy, + * 0: the page is dissolved (if needed) and not taken off from buddy, + * < 0: failed to dissolve. + */ +static int __page_handle_poison(struct page *page) { int ret; =20 @@ -81,7 +87,7 @@ static bool __page_handle_poison(struct page *page) ret =3D take_page_off_buddy(page); zone_pcp_enable(page_zone(page)); =20 - return ret > 0; + return ret; } =20 static bool page_handle_poison(struct page *page, bool hugepage_or_freepag= e, bool release) @@ -91,7 +97,7 @@ static bool page_handle_poison(struct page *page, bool hu= gepage_or_freepage, boo * Doing this check for free pages is also fine since dissolve_free_huge= _page * returns 0 for non-hugetlb pages as well. */ - if (!__page_handle_poison(page)) + if (__page_handle_poison(page) <=3D 0) /* * We could fail to take off the target page from buddy * for example due to racy page allocation, but that's @@ -1048,7 +1054,7 @@ static int me_huge_page(struct page_state *ps, struct= page *p) * subpages. */ put_page(hpage); - if (__page_handle_poison(p)) { + if (__page_handle_poison(p) > 0) { page_ref_inc(p); res =3D MF_RECOVERED; } @@ -1698,8 +1704,7 @@ static int try_memory_failure_hugetlb(unsigned long p= fn, int flags, int *hugetlb */ if (res =3D=3D 0) { unlock_page(head); - res =3D MF_FAILED; - if (__page_handle_poison(p)) { + if (__page_handle_poison(p) > 0) { page_ref_inc(p); res =3D MF_RECOVERED; } --=20 2.25.1 From nobody Mon Apr 20 01:09:47 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9F4E0C433EF for ; Thu, 23 Jun 2022 23:53:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231347AbiFWXxJ (ORCPT ); Thu, 23 Jun 2022 19:53:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57072 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231244AbiFWXw4 (ORCPT ); Thu, 23 Jun 2022 19:52:56 -0400 Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8DE1910F1 for ; Thu, 23 Jun 2022 16:52:53 -0700 (PDT) Received: by mail-pg1-x529.google.com with SMTP id h192so878265pgc.4 for ; Thu, 23 Jun 2022 16:52:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=LG1rSzGEsPK4iv+N/lwp5PXQGNIYUtfM/aAuTYkg0vc=; b=kp5Fq94l6Q8wgGQCHb0XGJwN4XF5JHuSExD/vq+W4HulxPu4y7NpXpzk0sC4IbGOF0 M8KAGgZc5kObwch9yTED6BTWncP2yvMtbr+bH+KSPK3guq1ThRAzdHSa+W71rWfvYi5Y ysRgIgyiMWh4MKt7L42JrZc5NkKFssOV2e5P4ICRr7BACAKuoQ/eu+QswjxOjsF8Qh9L /9q19zgN4ONQWZgUIzp2zk9FPdJ7T/61qXbmDITGTyaGcabR3hZpeQjiZAfpcM4Id7Ms ZxiNLZtA8OmC0bfzSoEwTbnAiH5hXBWlOsZ/GgJaKy63TSCZUNEzfRNHl4QZ+uHeTTH/ Cbxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=LG1rSzGEsPK4iv+N/lwp5PXQGNIYUtfM/aAuTYkg0vc=; b=Rf9POphUVuawOCUwtvG2fJ/qZr+RxT/6lKQlsnLl9gi1rP4qde5CE/l5dLzCo/+yWQ Ey63T8V1VTTFh+50hdFnxkSKWF3exqCF9OwuWSVTtYWuprBKTWplZZ44RJCOdoK5ruYg +I/cR6PBZgwBBJeFq4FArS9E5O7pF/bKrjr4eyLcJAOx7Zl4KRLPq0b/ueBvUYRBN7Kh JhPQM+pH0lD/MkhjaFV40Mb4O+uz/odJU05N26qdO8GHdFAc4IVBFks6p/XJ8ZxWur6b MstZ1g3qAx2/RfwjK8JCpX6I9u5+7oLAw8TI79POIYcV/JiZXihm5H/F0g47nzdrLBF1 e1HQ== X-Gm-Message-State: AJIora+uP2cs0XUNXKOiFrunz2B2UlX4gGeap2tQPK/huIIINbJo/KG+ KcI/JydZjHAhuuTRmaoYZA== X-Google-Smtp-Source: AGRyM1tcKr8yX9/tffiNeAaqH/kIj/EK53FgF4ggMpoeeio6m/TIPEIsDaxtlmNYN+u9v8W4FmnXEg== X-Received: by 2002:a62:6410:0:b0:4f3:9654:266d with SMTP id y16-20020a626410000000b004f39654266dmr43077948pfb.59.1656028372725; Thu, 23 Jun 2022 16:52:52 -0700 (PDT) Received: from ik1-406-35019.vs.sakura.ne.jp (ik1-406-35019.vs.sakura.ne.jp. [153.127.16.23]) by smtp.gmail.com with ESMTPSA id r10-20020a170903020a00b00168eab11f67sm362571plh.94.2022.06.23.16.52.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jun 2022 16:52:52 -0700 (PDT) From: Naoya Horiguchi X-Google-Original-From: Naoya Horiguchi To: linux-mm@kvack.org Cc: Andrew Morton , David Hildenbrand , Mike Kravetz , Miaohe Lin , Liu Shixin , Yang Shi , Oscar Salvador , Muchun Song , Naoya Horiguchi , linux-kernel@vger.kernel.org Subject: [PATCH v2 8/9] mm, hwpoison: skip raw hwpoison page in freeing 1GB hugepage Date: Fri, 24 Jun 2022 08:51:52 +0900 Message-Id: <20220623235153.2623702-9-naoya.horiguchi@linux.dev> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220623235153.2623702-1-naoya.horiguchi@linux.dev> References: <20220623235153.2623702-1-naoya.horiguchi@linux.dev> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Naoya Horiguchi Currently if memory_failure() (modified to remove blocking code with subsequent patch) is called on a page in some 1GB hugepage, memory error handling fails and the raw error page gets into leaked state. The impact is small in production systems (just leaked single 4kB page), but this limits the testability because unpoison doesn't work for it. We can no longer create 1GB hugepage on the 1GB physical address range with such leaked pages, that's not useful when testing on small systems. When a hwpoison page in a 1GB hugepage is handled, it's caught by the PageHWPoison check in free_pages_prepare() because the 1GB hugepage is broken down into raw error pages before coming to this point: if (unlikely(PageHWPoison(page)) && !order) { ... return false; } Then, the page is not sent to buddy and the page refcount is left 0. Originally this check is supposed to work when the error page is freed from page_handle_poison() (that is called from soft-offline), but now we are opening another path to call it, so the callers of __page_handle_poison() need to handle the case by considering the return value 0 as success. Then page refcount for hwpoison is properly incremented so unpoison works. Signed-off-by: Naoya Horiguchi Reviewed-by: Miaohe Lin --- mm/memory-failure.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/mm/memory-failure.c b/mm/memory-failure.c index db85f644a1e3..fc7b83cb6468 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -1046,7 +1046,6 @@ static int me_huge_page(struct page_state *ps, struct= page *p) res =3D truncate_error_page(hpage, page_to_pfn(p), mapping); unlock_page(hpage); } else { - res =3D MF_FAILED; unlock_page(hpage); /* * migration entry prevents later access on error hugepage, @@ -1054,9 +1053,11 @@ static int me_huge_page(struct page_state *ps, struc= t page *p) * subpages. */ put_page(hpage); - if (__page_handle_poison(p) > 0) { + if (__page_handle_poison(p) >=3D 0) { page_ref_inc(p); res =3D MF_RECOVERED; + } else { + res =3D MF_FAILED; } } =20 @@ -1704,9 +1705,11 @@ static int try_memory_failure_hugetlb(unsigned long = pfn, int flags, int *hugetlb */ if (res =3D=3D 0) { unlock_page(head); - if (__page_handle_poison(p) > 0) { + if (__page_handle_poison(p) >=3D 0) { page_ref_inc(p); res =3D MF_RECOVERED; + } else { + res =3D MF_FAILED; } action_result(pfn, MF_MSG_FREE_HUGE, res); return res =3D=3D MF_RECOVERED ? 0 : -EBUSY; --=20 2.25.1 From nobody Mon Apr 20 01:09:47 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 741D2C433EF for ; Thu, 23 Jun 2022 23:53:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231370AbiFWXxP (ORCPT ); Thu, 23 Jun 2022 19:53:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57124 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231277AbiFWXw6 (ORCPT ); Thu, 23 Jun 2022 19:52:58 -0400 Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 464E0B7F5 for ; Thu, 23 Jun 2022 16:52:56 -0700 (PDT) Received: by mail-pj1-x1034.google.com with SMTP id a11-20020a17090acb8b00b001eca0041455so4344301pju.1 for ; Thu, 23 Jun 2022 16:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=xlh5+JHPCpuQ09KawzKkUOlMCn4aWXR34ra2vrdN9hI=; b=MEmORMw9CoAhwNYfHfOlrZjmyaV1kxLa2ly8Bz617AoWw6gyQfA+eYRxSScDsayqSE vEeb04MRVgwYo6YZU8ahEfefgc7Zo/NiMU+DYL4YDwHrcNbicueEUnbIqQFX5doIy1jm /kCAQATYrsmfNaVqrDVcb6DJfAGw87zSOMdMLh1lLF7YOPPH/73bvPg34HTyM7tpRGUQ nOjgsZK4t5kglXK6qoK3JAYx7AQQTcRuk8Mj17qhHxTNgnF+Y7GasXDcNgFynTQE9W9L 95RsE1CJ9sfNpVvHVI83dPlXVdq3OhKVdl2cpSil4MWjqDhLx+Kv/eTTwb9LdbB6ZrXn bNEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=xlh5+JHPCpuQ09KawzKkUOlMCn4aWXR34ra2vrdN9hI=; b=FCIZvM3+6XuLd+PI7KgWRki0IDSCYKWTWuzMqTyEtSOJNXGdWGKQIy0Uhi1SCfwIGg W3eFBA+/dIqpzWavrrMQJ8lIyMePQvW34jNeoBO1f31q+THB/iPDb6HdeSaOB/AvDKsZ 4O5fj0fFTY6rVzXk18VvzdnjWZU24xcH/JzIrpdckz7y24oR6hUFK3PeOBmcVCHLeZI3 HQHIuzkmniQY2fcGC57Z8gL65Mt3lPXlg4cZRaP37t2M+OXnUjEC8Xvcy0TUMPTU8Zri DsNChRiCIWH8We2qvkzfFAu3G057yBfXQepChSAg3XEa6/ZyVAARX970kStT51wVHxAA lJBQ== X-Gm-Message-State: AJIora8NYzJzy3kN657tFJ30tJEVLyyJZKgFSYj7cqaFxQN5UHQBgVZ/ LWbcuV6ibaURNCd7dEIbWEyYPVoZUQ== X-Google-Smtp-Source: AGRyM1soNngnpVcfxmXaErJFMeKvhtVFxNIlwB4ItZCs2wn5DW3s5YIJ6hdZc7kgW4lJHxcSAIlZDg== X-Received: by 2002:a17:90b:1808:b0:1ec:9559:3060 with SMTP id lw8-20020a17090b180800b001ec95593060mr542906pjb.163.1656028375788; Thu, 23 Jun 2022 16:52:55 -0700 (PDT) Received: from ik1-406-35019.vs.sakura.ne.jp (ik1-406-35019.vs.sakura.ne.jp. [153.127.16.23]) by smtp.gmail.com with ESMTPSA id r10-20020a170903020a00b00168eab11f67sm362571plh.94.2022.06.23.16.52.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jun 2022 16:52:55 -0700 (PDT) From: Naoya Horiguchi X-Google-Original-From: Naoya Horiguchi To: linux-mm@kvack.org Cc: Andrew Morton , David Hildenbrand , Mike Kravetz , Miaohe Lin , Liu Shixin , Yang Shi , Oscar Salvador , Muchun Song , Naoya Horiguchi , linux-kernel@vger.kernel.org Subject: [PATCH v2 9/9] mm, hwpoison: enable memory error handling on 1GB hugepage Date: Fri, 24 Jun 2022 08:51:53 +0900 Message-Id: <20220623235153.2623702-10-naoya.horiguchi@linux.dev> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220623235153.2623702-1-naoya.horiguchi@linux.dev> References: <20220623235153.2623702-1-naoya.horiguchi@linux.dev> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Naoya Horiguchi Now error handling code is prepared, so remove the blocking code and enable memory error handling on 1GB hugepage. Signed-off-by: Naoya Horiguchi Reviewed-by: Miaohe Lin --- include/linux/mm.h | 1 - include/ras/ras_event.h | 1 - mm/memory-failure.c | 16 ---------------- 3 files changed, 18 deletions(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index 044dc5a2e361..9d7e9b5a4d1d 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -3284,7 +3284,6 @@ enum mf_action_page_type { MF_MSG_DIFFERENT_COMPOUND, MF_MSG_HUGE, MF_MSG_FREE_HUGE, - MF_MSG_NON_PMD_HUGE, MF_MSG_UNMAP_FAILED, MF_MSG_DIRTY_SWAPCACHE, MF_MSG_CLEAN_SWAPCACHE, diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h index d0337a41141c..cbd3ddd7c33d 100644 --- a/include/ras/ras_event.h +++ b/include/ras/ras_event.h @@ -360,7 +360,6 @@ TRACE_EVENT(aer_event, EM ( MF_MSG_DIFFERENT_COMPOUND, "different compound page after locking" )= \ EM ( MF_MSG_HUGE, "huge page" ) \ EM ( MF_MSG_FREE_HUGE, "free huge page" ) \ - EM ( MF_MSG_NON_PMD_HUGE, "non-pmd-sized huge page" ) \ EM ( MF_MSG_UNMAP_FAILED, "unmapping failed page" ) \ EM ( MF_MSG_DIRTY_SWAPCACHE, "dirty swapcache page" ) \ EM ( MF_MSG_CLEAN_SWAPCACHE, "clean swapcache page" ) \ diff --git a/mm/memory-failure.c b/mm/memory-failure.c index fc7b83cb6468..33521e059f7f 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -728,7 +728,6 @@ static const char * const action_page_types[] =3D { [MF_MSG_DIFFERENT_COMPOUND] =3D "different compound page after locking", [MF_MSG_HUGE] =3D "huge page", [MF_MSG_FREE_HUGE] =3D "free huge page", - [MF_MSG_NON_PMD_HUGE] =3D "non-pmd-sized huge page", [MF_MSG_UNMAP_FAILED] =3D "unmapping failed page", [MF_MSG_DIRTY_SWAPCACHE] =3D "dirty swapcache page", [MF_MSG_CLEAN_SWAPCACHE] =3D "clean swapcache page", @@ -1717,21 +1716,6 @@ static int try_memory_failure_hugetlb(unsigned long = pfn, int flags, int *hugetlb =20 page_flags =3D head->flags; =20 - /* - * TODO: hwpoison for pud-sized hugetlb doesn't work right now, so - * simply disable it. In order to make it work properly, we need - * make sure that: - * - conversion of a pud that maps an error hugetlb into hwpoison - * entry properly works, and - * - other mm code walking over page table is aware of pud-aligned - * hwpoison entries. - */ - if (huge_page_size(page_hstate(head)) > PMD_SIZE) { - action_result(pfn, MF_MSG_NON_PMD_HUGE, MF_IGNORED); - res =3D -EBUSY; - goto out; - } - if (!hwpoison_user_mappings(p, pfn, flags, head)) { action_result(pfn, MF_MSG_UNMAP_FAILED, MF_IGNORED); res =3D -EBUSY; --=20 2.25.1