Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp6325204iog; Thu, 23 Jun 2022 16:54:19 -0700 (PDT) X-Google-Smtp-Source: AGRyM1snb4I0/earzuLEfyB8Zfi6Pd8U+jhIDOIpVpy2SJlfImhSXZTlSjuVQBKbGdwW6IcV5PKp X-Received: by 2002:a17:906:c041:b0:718:c984:d9ee with SMTP id bm1-20020a170906c04100b00718c984d9eemr11049998ejb.722.1656028459666; Thu, 23 Jun 2022 16:54:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656028459; cv=none; d=google.com; s=arc-20160816; b=hsfjTEK7CIDXDdTvoXZcgXiE2IvOVY+wuoEJNuXQiHNFjkvkqn56Ae2nojSP5L2VWQ vykQwBDDIbWLdOOZqfna0tLsYTYunXJrgNxp3Tlm94bM4IgZ7n6PoVuZ8A5K08Ch73cR RdrYBXa087rbQ53CVT4dkS/utBiZwkJ6CZB/nbcwyTg00DRaCb8xA2BElE40LPasn52x AQZ9U3NKquEUC/CRinu2clQPOmf/9JYAX1tAmnq+cA3PMfB6QlVfus30nksMAsjyxqjt 12i2C5Fcdc7ceXS+Ofcnh/XTArD83bLHo6Xcb0zxPdh+CxAmU5WFxqor65/FBf3ppseT XpwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=DefBYaY/G33kY4Ei9AvXETroX4rt5wpVrX5H893xFe8=; b=MT8OVRC094kYsE5cv2HR5ED98eSfEgXdqTkbt7FXOOKCdBm40W0NMIqNudcv9irgwa 8P1pSqC7SjTAGP4d6GI78J7Owzb5LGDiB6GoM8+1hhQ8d7sq8x9gR3yHzahq8oo/w5Ds i/bfMpKVdKE1FSq84UIDzWYuJx3hANPNYbDXNFPsqoaWKnfgbOYmJkDit8xPu5xBHI5O nnxF20Ii0rfxUScG8nWFiOp/evnAJ2vOxik94CeFQfOLk2Xfv+WkUL8yuN/EXTT4h62e 9He3ZQwVH01hLJdCdPBP82BpEQvcoKyu3ZrFPJmd/x+TPo0W5K3W2aMdBi5Un5h6PxAv aVHg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=Sy4dpBK9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l17-20020a056402255100b0042b816bcc59si1518358edb.127.2022.06.23.16.53.29; Thu, 23 Jun 2022 16:54:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=Sy4dpBK9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230519AbiFWXwY (ORCPT + 99 others); Thu, 23 Jun 2022 19:52:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56448 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229505AbiFWXwX (ORCPT ); Thu, 23 Jun 2022 19:52:23 -0400 Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E08F3609E6 for ; Thu, 23 Jun 2022 16:52:21 -0700 (PDT) Received: by mail-pj1-x1032.google.com with SMTP id go6so1171414pjb.0 for ; Thu, 23 Jun 2022 16:52:21 -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:mime-version :content-transfer-encoding; bh=DefBYaY/G33kY4Ei9AvXETroX4rt5wpVrX5H893xFe8=; b=Sy4dpBK9sxm6P1WYqg3D7g3GCUd2xUq4x6AnHGjjnZ47T/sRJJjc+j4mWPXxBkFEog UfgGJJ/C3IVk9qX/R35CfCkxoJfLiiGuDPL/CjKxCDhatzE5d6L/bId9gF/Ly1abut+j /rSa+f/H32w8OoUvMKNIRmqfV18iOSY/2h0pvrt9iba25lUmFSq7XPERVAFN+f8Jq1W4 lduN9LuS+ajFQ5q9rUIcl3i2lh09TtzIdBke9RxcDPtbwsS2kXOeUlv3R0lFsAqIcdXS 846pHtNAJS22q7crZjwXOqoAV29uCgF4ZgUC4QiV2+lzpeoVQHYZ/JtMmT7oPW8mRlO8 gcdA== 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:mime-version :content-transfer-encoding; bh=DefBYaY/G33kY4Ei9AvXETroX4rt5wpVrX5H893xFe8=; b=pEjjYk9MNskMWeGU4BHAs2FbmNzBX+FYlkzgoWb2FR4ENgha9JrHGH1otgVf3E0Qjz kTgUAqubWldSoOorKoRoPSujEso35KLXwFDvWZSlFZI4Lhy1+EKnePOPiiF6thBKeG4X C3itj/usbeHnIahmH/hTXZn33sSyTkmTc5OVPlmulSI4+QqnT7L2Yw0RdKlRhXONpFfQ 8Ua2qBwxNPnHJQnhMfrpnUJC/96+jlu9JWjFb0mEHwy1TFpmNNyjTXg0mGsxJVmylgww g7anYwk7TPCo8sM+xGBQBSrCFZgDJ7Jgo/477EnVAhxDWTyttkYToMmvxkVhiBBsH0hF m1Zw== X-Gm-Message-State: AJIora9SfiWRrNamSQ9XFV0t6yOP1TE9DZ/dSjMbUlENR2jqnE6MkO1X zRRqf/tCTaasL/DO76HL2A== X-Received: by 2002:a17:903:234e:b0:16a:2d02:add7 with SMTP id c14-20020a170903234e00b0016a2d02add7mr19621461plh.10.1656028341391; Thu, 23 Jun 2022 16:52:21 -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.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jun 2022 16:52:21 -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 0/9] mm, hwpoison: enable 1GB hugepage support (v2) Date: Fri, 24 Jun 2022 08:51:44 +0900 Message-Id: <20220623235153.2623702-1-naoya.horiguchi@linux.dev> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Here is v2 of "enabling memory error handling on 1GB hugepage" patchset. Major updates: - (patch 3/9) I made pud_huge() and follow_huge_pud() aware of non-present pud entry (based on Miaohe's comment). - (patch 4/9 and patch 5/9) I extended the mechanism to save raw error info to support multiple error subpages in a hugepage. Additionally, I added a "unreliable" flag which prevents freeing hwpoison hugetlb if any raw error info is lost. - (patch 1/9 and 2/9) During testing some common cases for 1GB hugepage, I found a few issues in existing code, so this series starts with fixing them. The remaining patches should have only minor updates since v1. Patch dependency: - "mm/memory-failure: disable unpoison once hw error happens" (actually the conflict is not logical one, but adding MF_SIMULATED to mf_flags conflicts with patch 6/9.) v1: https://lore.kernel.org/linux-mm/20220602050631.771414-1-naoya.horiguchi@linux.dev/T/#u Thanks, Naoya Horiguchi --- Summary: Naoya Horiguchi (9): mm/hugetlb: remove checking hstate_is_gigantic() in return_unused_surplus_pages() mm/hugetlb: separate path for hwpoison entry in copy_hugetlb_page_range() mm/hugetlb: make pud_huge() and huge_pud() aware of non-present pud entry mm, hwpoison, hugetlb: support saving mechanism of raw error pages mm, hwpoison: make unpoison aware of raw error info in hwpoisoned hugepage mm, hwpoison: set PG_hwpoison for busy hugetlb pages mm, hwpoison: make __page_handle_poison returns int mm, hwpoison: skip raw hwpoison page in freeing 1GB hugepage mm, hwpoison: enable memory error handling on 1GB hugepage arch/x86/mm/hugetlbpage.c | 3 +- include/linux/hugetlb.h | 13 ++++ include/linux/mm.h | 2 +- include/linux/swapops.h | 9 +++ include/ras/ras_event.h | 1 - mm/hugetlb.c | 78 ++++++++++++++-------- mm/memory-failure.c | 163 +++++++++++++++++++++++++++++++++++++--------- 7 files changed, 209 insertions(+), 60 deletions(-)