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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 16D65C4332F for ; Thu, 20 Oct 2022 18:27:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A1D278E0002; Thu, 20 Oct 2022 14:27:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9CD298E0001; Thu, 20 Oct 2022 14:27:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8BC3E8E0002; Thu, 20 Oct 2022 14:27:48 -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 7CC908E0001 for ; Thu, 20 Oct 2022 14:27:48 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2EC2E1204F1 for ; Thu, 20 Oct 2022 18:27:48 +0000 (UTC) X-FDA: 80042161416.23.17979AE Received: from mail-pj1-f45.google.com (mail-pj1-f45.google.com [209.85.216.45]) by imf15.hostedemail.com (Postfix) with ESMTP id D18BEA000B for ; Thu, 20 Oct 2022 18:27:47 +0000 (UTC) Received: by mail-pj1-f45.google.com with SMTP id t10-20020a17090a4e4a00b0020af4bcae10so416529pjl.3 for ; Thu, 20 Oct 2022 11:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0tIx6HdnxvvsDqhgjFe+ArvgpH3bDXYD7273dNF1cgU=; b=dSRDUfwp+jfghkbPv9BNEbmWn5jNVVAAUmaqmB1sJ/4psJI9erOuxkOeUT+D+ih4nG 6xUsapOGqaGBMHdQh4qHit0J5dNG47yVxcNVmyaIExVIfwerrD6gm6PxoPGAtS3AQVsj JNHDFC6w8vK4P0p7ZX7H++T2iwIvk1YwFMBCoPjMPnz/+gEzDHFPivL5/CoUO55fgLQz ynywAHWRCJFlI1DgxrN7Shb3aa6XfNT0fc+oYxcptVjY+QuhA5Yu++7CYs5r+D2rf1Wr eNPj+PzZo86qf5N+lO7ZIWDWiIzDARuFgsiWpagsKP51ifTw8djpCC0bRYqZfGunPfGX 4rog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0tIx6HdnxvvsDqhgjFe+ArvgpH3bDXYD7273dNF1cgU=; b=VA3M5EeOGSZiX8nDnJEzGb7gKo+2T3pUbwvheT9pxCgJem6Tr/By2m7nLxV2D7izeP 0NzLgG/9dB9qJGr4X9tyrgDSbfk4tMOjdwxkvrFLPgsf18Uu3vQK7g5i1U10EC274uUy z99SlCqsdwcJRBmL21VqSJXBkKRsMAZUe+sifHqCiV1ER7gxe9a3xoW9SLhILjSPzI3N 7cIUJiVdLRiEy7hixZb9qftsGBgW0V/juo0AbOwkVC1IlQk8W0y4cO3H30wwHmP6h2ub eqkaXfr8IFIZ5rEbNzLY6bj/lPL1s15RbwNDZdZCiclm4Hog9DxuXPPryoDQMHxuPDyd 5x8g== X-Gm-Message-State: ACrzQf2f1770r9Jne2ThGNjeP238q8sGVscvRX0WdlHLw4cJfehz5bQ1 JxjgLwzzamVb3SCffJyJXMNTOouJ+18F0nR+pIo= X-Google-Smtp-Source: AMsMyM6l7jPlCkpp6teBaQ2qsDbSYRodsLiWbU/KFD5M8VnN7xNmjW0TSzthjck2HP04OBtttwh34jp+rkZcdngtdYs= X-Received: by 2002:a17:902:d512:b0:181:f1f4:fcb4 with SMTP id b18-20020a170902d51200b00181f1f4fcb4mr15353550plg.102.1666290466641; Thu, 20 Oct 2022 11:27:46 -0700 (PDT) MIME-Version: 1.0 References: <20221018200125.848471-1-jthoughton@google.com> In-Reply-To: From: Yang Shi Date: Thu, 20 Oct 2022 11:27:34 -0700 Message-ID: Subject: Re: [PATCH] hugetlbfs: don't delete error page from pagecache To: James Houghton Cc: Mike Kravetz , Muchun Song , Naoya Horiguchi , Miaohe Lin , Andrew Morton , Axel Rasmussen , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666290467; a=rsa-sha256; cv=none; b=rmov6bft6oYqRUuB55jy6F/UE7YBcH/mEzwHHosdZNuOrKRh3PXkNGGVJh20lbQ1noH0VH W+zySU6pLY66uNG5LXFgI01iI0hdqUAafR13vmBp7rG1QpChVk/gAo3Xn1Fv35m5h/48gV qH5OV61peZ9SNVlJPwAWLCgrSf89fzg= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=dSRDUfwp; spf=pass (imf15.hostedemail.com: domain of shy828301@gmail.com designates 209.85.216.45 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666290467; 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-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0tIx6HdnxvvsDqhgjFe+ArvgpH3bDXYD7273dNF1cgU=; b=aPhPB3wjaF6qz45x7o2FwUPwNTnV6J7J2aIinRJ8qj3KPBhK5ESrBiK/z4Fl5NJZZ9vGHu 1TXOlpytaV0lSAn+64+zXKlxrlOSpjLcZ3Np8fQnzYAGG+91FjV9RIWqrdGW+69DL1PI+J GIJXw5Ro3WOZDHFsyQdq8GGjSJcmWqg= X-Rspam-User: Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=dSRDUfwp; spf=pass (imf15.hostedemail.com: domain of shy828301@gmail.com designates 209.85.216.45 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: 9zb9pnizwegys1cpycs1cn9jthf1ktz5 X-Rspamd-Queue-Id: D18BEA000B X-Rspamd-Server: rspam10 X-HE-Tag: 1666290467-21874 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: On Wed, Oct 19, 2022 at 11:42 AM James Houghton wrote: > > On Wed, Oct 19, 2022 at 11:31 AM Yang Shi wrote: > > > > On Tue, Oct 18, 2022 at 1:01 PM James Houghton wrote: > > > > > > 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") > > > > > > Signed-off-by: James Houghton > > > > Thanks for the patch. Yes, we should do the same thing for hugetlbfs. > > When I was working on shmem I did look into hugetlbfs too. But the > > problem is we actually make the whole hugetlb page unavailable even > > though just one 4K sub page is hwpoisoned. It may be fine to 2M > > hugetlb page, but a lot of memory may be a huge waste for 1G hugetlb > > page, particular for the page fault path. > > Right -- it is wasted until a hole is punched or the file is > truncated. Although we're wasting the rest of the hugepage for a > little longer with this patch, I think it's worth it to have correct > behavior. > > > > > So I discussed this with Mike offline last year, and I was told Google > > was working on PTE mapped hugetlb page. That should be able to solve > > the problem. And we'd like to have the high-granularity hugetlb > > mapping support as the predecessor. > > > > There were some other details, but I can't remember all of them, I > > have to refresh my memory by rereading the email discussions... > > Yes! I am working on this. :) I will send up a series in the coming > weeks that implements basic support for high-granularity mapping > (HGM). This patch is required for hwpoison semantics to work properly > for high-granularity mapping (and, as the patch states, for shared > HugeTLB mappings generally). For HGM, if we partially map a hugepage > and find poison, faulting on the unmapped bits of it will allocate a > new hugepage. By keeping the poisoned page in the pagecache, we > correctly give userspace a SIGBUS. I didn't mention this in the commit > description because I think this patch is correct on its own. I don't mean it is not correct. I'm not sure which one (this patch or HGM) would go first. But it sounds like you thought this patch should be the predecessor of HGM since it could deliver userspace the correct signal? > > I haven't implemented PAGE_SIZE poisoning of HugeTLB pages yet, but > high-granularity mapping unblocks this work. Hopefully that will be > ready in the coming months. :) > > - James Houghton > > > > > > --- > > > 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 fef5165b73a5..7f836f8f9db1 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_folio(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 97896165fd3f..5120a9ccbf5b 100644 > > > --- a/mm/hugetlb.c > > > +++ b/mm/hugetlb.c > > > @@ -6101,6 +6101,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; > > > -- > > > 2.38.0.413.g74048e4d9e-goog > > >