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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3C688CCA47E for ; Mon, 27 Jun 2022 19:32:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237239AbiF0TcD (ORCPT ); Mon, 27 Jun 2022 15:32:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50308 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235627AbiF0TcB (ORCPT ); Mon, 27 Jun 2022 15:32:01 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 48ED622C for ; Mon, 27 Jun 2022 12:31:59 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2A666615C9 for ; Mon, 27 Jun 2022 19:31:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7BCA5C341CA; Mon, 27 Jun 2022 19:31:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1656358318; bh=jbZ3RcZyR2GOYsBtB/ui1TN3W0dr3fuNsyFrJ3jw5dI=; h=Date:To:From:Subject:From; b=xWrPfOAPk5t+empS12eS33IMF8q3OPTQMLEO7QQRhMmxQeTEsjrZoWW5AwJrrH7cJ EpM6A8Ge51yKSHTXmTvNqQK1HiqBrAXpOuATU77I0Oros/JK/vqhWydWcJUX33zUxc 7NFgUHivVZT+Oe6cfdp0VPYTsMSUzaD8p1gHXuqs= Date: Mon, 27 Jun 2022 12:31:57 -0700 To: mm-commits@vger.kernel.org, songmuchun@bytedance.com, shy828301@gmail.com, osalvador@suse.de, mike.kravetz@oracle.com, liushixin2@huawei.com, linmiaohe@huawei.com, david@redhat.com, naoya.horiguchi@nec.com, akpm@linux-foundation.org From: Andrew Morton Subject: [to-be-updated] mm-hwpoison-skip-raw-hwpoison-page-in-freeing-1gb-hugepage.patch removed from -mm tree Message-Id: <20220627193158.7BCA5C341CA@smtp.kernel.org> Precedence: bulk Reply-To: linux-kernel@vger.kernel.org List-ID: X-Mailing-List: mm-commits@vger.kernel.org The quilt patch titled Subject: mm, hwpoison: skip raw hwpoison page in freeing 1GB hugepage has been removed from the -mm tree. Its filename was mm-hwpoison-skip-raw-hwpoison-page-in-freeing-1gb-hugepage.patch This patch was dropped because an updated version will be merged ------------------------------------------------------ From: Naoya Horiguchi Subject: mm, hwpoison: skip raw hwpoison page in freeing 1GB hugepage Date: Thu, 2 Jun 2022 14:06:30 +0900 Currently if memory_failure() (modified to remove blocking code) is called on a page in some 1GB hugepage, memory error handling returns failure and the raw error page gets into undesirable state. The impact is small in production systems (just leaked single 4kB page), but this limits the test efficiency because unpoison doesn't work for it. So we can no longer create 1GB hugepage on the 1GB physical address range with such hwpoison pages, that could be an issue in 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 hugepage is broken down into raw error page and order is 0: 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 and now unpoison works. Link: https://lkml.kernel.org/r/20220602050631.771414-5-naoya.horiguchi@linux.dev Signed-off-by: Naoya Horiguchi Reviewed-by: Miaohe Lin Cc: David Hildenbrand Cc: Liu Shixin Cc: Mike Kravetz Cc: Muchun Song Cc: Oscar Salvador Cc: Yang Shi Signed-off-by: Andrew Morton --- mm/memory-failure.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- a/mm/memory-failure.c~mm-hwpoison-skip-raw-hwpoison-page-in-freeing-1gb-hugepage +++ a/mm/memory-failure.c @@ -1046,7 +1046,6 @@ static int me_huge_page(struct page_stat 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_stat * 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; } } @@ -1604,9 +1605,11 @@ retry: */ 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; _ Patches currently in -mm which might be from naoya.horiguchi@nec.com are mm-hwpoison-enable-memory-error-handling-on-1gb-hugepage.patch