From patchwork Mon Nov 7 18:05:48 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: James Houghton X-Patchwork-Id: 16633 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp2209455wru; Mon, 7 Nov 2022 10:10:43 -0800 (PST) X-Google-Smtp-Source: AMsMyM6owkgjq9MkPnyb3n5W3jAie8yAqJ3Ef573qc4FRq1Ry1uBqoHc4+IirHZ8jhoXMHyQakJP X-Received: by 2002:aa7:c718:0:b0:462:ff35:95dc with SMTP id i24-20020aa7c718000000b00462ff3595dcmr50383453edq.32.1667844642991; Mon, 07 Nov 2022 10:10:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1667844642; cv=none; d=google.com; s=arc-20160816; b=Yhz75SMQsXagOSaPPUkqsua1dZFnLEsQcEqEw1Jpwi6SoCfTGqrD4tpbumoBqUxqPk AgrNGapkKZfV6PdhqlvLODMrG7r5wRYmkKOvnTP4iEoj6oZBMaHOuNmkeDC2OfKDD6ev 3MHHNCU8PCORTCVyWjLUJiOnCL1IK/76jBUhiaV+WnGx9TQp5YrTL/jUB4x4M1pTSISb gT/Ho3z5oYrGDDVY7xpo6mg/rRgjdXWGYdChWEPDKDWhCoJHmyPKeOWaiFBsuQvJ+VbR VHTNEICyCGFnfEIO+0Te55l2tJB4NVbbmdLaVQH8icnMLRfFlG5b6GaeZdmT7RHYhity T/5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:mime-version:date :dkim-signature; bh=j60fk1GX1r+NlL9MlNZCmp8WSDoORaTrNw5+KLoJy/4=; b=Q5h9QHHiL2NLqETinOt9+BmVj4t1XZ7s5+KGt7KG3NEWeyTdRyseFWg8Sgmf9YdQAp g9XGgNYiPoHCLA2tf5ioPmaRcZNy44+c55vQmyDMN4713m0Syp85+ZVaGAr2kIfwtf6w M/3/H1OscJr1w1HQR2v5l9obaxyIl65ECqH46BsjE2e9LkzPzTWIg9WyZZO1pYELMEM+ Z7jO/0Lp7RYBhuyJKVPHe4lk7rJXWjy4dNHomWZHZEsr8kvT5+baZcApyeNa8TGGUgJs nfagWeNActhobdI307jzdQSmt7hr8rKd//LFz2FMY04oFwftubuiX3gc5WYyAHlY+zak pdgw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=Mf6r8tPr; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z10-20020a05640235ca00b0045ce40540ebsi11765877edc.269.2022.11.07.10.10.16; Mon, 07 Nov 2022 10:10:42 -0800 (PST) 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=@google.com header.s=20210112 header.b=Mf6r8tPr; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231698AbiKGSJt (ORCPT + 99 others); Mon, 7 Nov 2022 13:09:49 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52616 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232545AbiKGSJf (ORCPT ); Mon, 7 Nov 2022 13:09:35 -0500 Received: from mail-yw1-x1149.google.com (mail-yw1-x1149.google.com [IPv6:2607:f8b0:4864:20::1149]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4333226545 for ; Mon, 7 Nov 2022 10:06:09 -0800 (PST) Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-37360a6236fso115083757b3.12 for ; Mon, 07 Nov 2022 10:06:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=j60fk1GX1r+NlL9MlNZCmp8WSDoORaTrNw5+KLoJy/4=; b=Mf6r8tPrYM3LamVKchqSLk/dmvuFcNjB5NxU9/TNA/LJR4+Uh6XqGidKCN9FLz9j6m 5gN67h9p+bLYpCjhvc8IX2CAcX4UVPj8TTNmTLQlD8LZNhhCBfuUhNVOyi4YFV9Cslm6 AhdPCARfNOufm6rPh+qX4CH2KdXaRwv31osB1U4pHViwGvPXTpaxGAj8nSPx7FSGxRB4 +bKsZS3bxkBP2fqFSyYSg3BcOjx2bkaxsJ2wtpBxsnFPpuiZfD1FUTU7e48qA9xSUo21 QvC3cJW2wJT2ZTT75eLJOPbDmwnzWYEohD/r29NC7k+wM2btkY3eRlPA4CapntnDrd5R pr/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=j60fk1GX1r+NlL9MlNZCmp8WSDoORaTrNw5+KLoJy/4=; b=AfDCG3rTCaBTOhQ+MVN96R4U7sHFMSzdbxFDwfe0CZVrr7+durs4Kwy32LrSsxkImF U9AgdYuZnWOWT6oPAxflD4XmiSKyDww+36xal52AoeoMgF9Sm81vQZn/8ogrYLP9Xcd/ IXb2XJepYtsJo+CshJZ60C14zOxSA+4TY3D8Aby0XUcOyQKQX3YdikGFqYl5fUQ39KhW VuofDyzUEagdsZk/Lk8ihSPq6ghXW/ejgI0sysXdb5wL9ddT7FTfhiG1WeQSuXxVORDl e6xU8V3cdLVJ2Z1kUkcXGzz6hkUpxUDk7nY1AI3kstvILPlOvoK/PO+LLfGuKXxZy0eP bi2A== X-Gm-Message-State: ACrzQf1MOG3Fmoc4XfpYnCctAx1gvpQC6Iue3wyiVKvNEo7Q9RmuwcxP Ed7jFIxICSfe9y0Ez7IP8byh/Aa5HdGRBTAi X-Received: from jthoughton.c.googlers.com ([fda3:e722:ac3:cc00:14:4d90:c0a8:2a4f]) (user=jthoughton job=sendgmr) by 2002:a81:e0f:0:b0:349:a047:655e with SMTP id 15-20020a810e0f000000b00349a047655emr50840803ywo.373.1667844368522; Mon, 07 Nov 2022 10:06:08 -0800 (PST) Date: Mon, 7 Nov 2022 18:05:48 +0000 Mime-Version: 1.0 X-Mailer: git-send-email 2.38.1.431.g37b22c650d-goog Message-ID: <20221107180548.2095056-1-jthoughton@google.com> Subject: [PATCH v2] hugetlbfs: don't delete error page from pagecache From: James Houghton To: Mike Kravetz , Muchun Song , Naoya Horiguchi , Miaohe Lin , Andrew Morton Cc: Yang Shi , Axel Rasmussen , linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, James Houghton X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1748861864480717391?= X-GMAIL-MSGID: =?utf-8?q?1748861864480717391?= This change is very similar to the change that was made for shmem [1], and it solves the same problem but for HugeTLBFS instead. Currently, when poison is found in a HugeTLB page, the page is removed from the page cache. That means that attempting to map or read that hugepage in the future will result in a new hugepage being allocated instead of notifying the user that the page was poisoned. As [1] states, this is effectively memory corruption. The fix is to leave the page in the page cache. If the user attempts to use a poisoned HugeTLB page with a syscall, the syscall will fail with EIO, the same error code that shmem uses. For attempts to map the page, the thread will get a BUS_MCEERR_AR SIGBUS. [1]: commit a76054266661 ("mm: shmem: don't truncate page if memory failure happens") Fixes: 78bb920344b8 ("mm: hwpoison: dissolve in-use hugepage in unrecoverable memory error") Cc: Signed-off-by: James Houghton Reviewed-by: Mike Kravetz Reviewed-by: Naoya Horiguchi Tested-by: Naoya Horiguchi Reviewed-by: Yang Shi --- fs/hugetlbfs/inode.c | 13 ++++++------- mm/hugetlb.c | 4 ++++ mm/memory-failure.c | 5 ++++- 3 files changed, 14 insertions(+), 8 deletions(-) diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index dd54f67e47fd..df7772335dc0 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -328,6 +328,12 @@ static ssize_t hugetlbfs_read_iter(struct kiocb *iocb, struct iov_iter *to) } else { unlock_page(page); + if (PageHWPoison(page)) { + put_page(page); + retval = -EIO; + break; + } + /* * We have the page, copy it to user space buffer. */ @@ -1111,13 +1117,6 @@ static int hugetlbfs_migrate_folio(struct address_space *mapping, static int hugetlbfs_error_remove_page(struct address_space *mapping, struct page *page) { - struct inode *inode = mapping->host; - pgoff_t index = page->index; - - hugetlb_delete_from_page_cache(page); - if (unlikely(hugetlb_unreserve_pages(inode, index, index + 1, 1))) - hugetlb_fix_reserve_counts(inode); - return 0; } diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 546df97c31e4..e48f8ef45b17 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -6111,6 +6111,10 @@ int hugetlb_mcopy_atomic_pte(struct mm_struct *dst_mm, ptl = huge_pte_lock(h, dst_mm, dst_pte); + ret = -EIO; + if (PageHWPoison(page)) + goto out_release_unlock; + /* * We allow to overwrite a pte marker: consider when both MISSING|WP * registered, we firstly wr-protect a none pte which has no page cache diff --git a/mm/memory-failure.c b/mm/memory-failure.c index 145bb561ddb3..bead6bccc7f2 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -1080,6 +1080,7 @@ static int me_huge_page(struct page_state *ps, struct page *p) int res; struct page *hpage = compound_head(p); struct address_space *mapping; + bool extra_pins = false; if (!PageHuge(hpage)) return MF_DELAYED; @@ -1087,6 +1088,8 @@ static int me_huge_page(struct page_state *ps, struct page *p) mapping = page_mapping(hpage); if (mapping) { res = truncate_error_page(hpage, page_to_pfn(p), mapping); + /* The page is kept in page cache. */ + extra_pins = true; unlock_page(hpage); } else { unlock_page(hpage); @@ -1104,7 +1107,7 @@ static int me_huge_page(struct page_state *ps, struct page *p) } } - if (has_extra_refcount(ps, p, false)) + if (has_extra_refcount(ps, p, extra_pins)) res = MF_FAILED; return res;