From patchwork Thu Jun 23 23:51:52 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Naoya Horiguchi X-Patchwork-Id: 12893262 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 F1778C433EF for ; Thu, 23 Jun 2022 23:52:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8DFE88E01AD; Thu, 23 Jun 2022 19:52:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 88EDE8E01A1; Thu, 23 Jun 2022 19:52:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 730418E01AD; Thu, 23 Jun 2022 19:52:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 653428E01A1 for ; Thu, 23 Jun 2022 19:52:54 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 3082C120575 for ; Thu, 23 Jun 2022 23:52:54 +0000 (UTC) X-FDA: 79611153468.25.B3048BA Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com [209.85.215.181]) by imf06.hostedemail.com (Postfix) with ESMTP id DCD31180012 for ; Thu, 23 Jun 2022 23:52:53 +0000 (UTC) Received: by mail-pg1-f181.google.com with SMTP id g186so887193pgc.1 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=AKxmLZhzoJ/bc3M+ixkv4nJCjFrxqwNeauajAEnMGulbp5KQGfbFIePRMNkc/ZqEc+ /STpcmDWDJyMryQQuM25BNKKVzyy/PJ0znwW3yz5kWYYeDS0xcDGT+5I/3pzANgUVyBV AYECCU+fIq33yVDkEw8teNbfcNmTikAX0sJHWNHkCAkjvMbzumQ8LB+dOci1tVwQ/KEd PnaAX79Cd9G6s6fVSyscOE4vQmJV1Xypyi+EPMze0CciXLvjPBc0N7gO6U0Xul0URqKb /Uu2DyfACsHZLlkoc6yqPIs0WTG1JPiopz+F83ImZz5pst8N8rOlfJc9bUfTZ9bUUbwq IRBA== X-Gm-Message-State: AJIora+X462VdsWImJiCLHVDERtAFblZQrIBFQThfauYlXp0tQ7O4INs uDFse6wkEmbvHutzBLJ2+KgsceBNdg== 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 ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656028373; a=rsa-sha256; cv=none; b=RfyywpZ3yZl59Y+36bGZvia7F7Odf9/1aoFQyZkIm2U9y3kETX++niuIjkRhY4umDaNmgK ek0lpC5eHr28MrXml7OP6Ja0nH25xOI04RLHtQXe3bYO0UVFD54oExsOEUff3TQEKatV/c Ep++Rv+qdfH8KdF0w+YP8Uaiew+nolY= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=kp5Fq94l; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf06.hostedemail.com: domain of nao.horiguchi@gmail.com designates 209.85.215.181 as permitted sender) smtp.mailfrom=nao.horiguchi@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656028373; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=LG1rSzGEsPK4iv+N/lwp5PXQGNIYUtfM/aAuTYkg0vc=; b=45m/NMjDvsAceEBMmv7qlNsFMsyciWS2M8WdjrkM7C6alX+nhwCoYaEQKWmOIBoB2fYYeS f8G6oCNTkJx5JdEqbxmuFIWUtUdN3EuYx47mSt5qVrF0JMQN+N7KlDt3Lj2+AH37TRH6ql NL5rXWKyHjyay2SWqz+LjhYixyyWBM4= X-Rspam-User: X-Stat-Signature: tzhqz8jb3nfyoq9qcki9othupt4yd6yj X-Rspamd-Queue-Id: DCD31180012 Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=kp5Fq94l; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf06.hostedemail.com: domain of nao.horiguchi@gmail.com designates 209.85.215.181 as permitted sender) smtp.mailfrom=nao.horiguchi@gmail.com X-Rspamd-Server: rspam03 X-HE-Tag: 1656028373-551821 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: 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 = truncate_error_page(hpage, page_to_pfn(p), mapping); unlock_page(hpage); } else { - res = 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, struct page *p) * subpages. */ put_page(hpage); - if (__page_handle_poison(p) > 0) { + if (__page_handle_poison(p) >= 0) { page_ref_inc(p); res = MF_RECOVERED; + } else { + res = MF_FAILED; } } @@ -1704,9 +1705,11 @@ static int try_memory_failure_hugetlb(unsigned long pfn, int flags, int *hugetlb */ if (res == 0) { unlock_page(head); - if (__page_handle_poison(p) > 0) { + if (__page_handle_poison(p) >= 0) { page_ref_inc(p); res = MF_RECOVERED; + } else { + res = MF_FAILED; } action_result(pfn, MF_MSG_FREE_HUGE, res); return res == MF_RECOVERED ? 0 : -EBUSY;