From: "HORIGUCHI NAOYA(堀口 直也)" <naoya.horiguchi@nec.com>
To: Yang Shi <shy828301@gmail.com>
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux MM <linux-mm@kvack.org>, Hugh Dickins <hughd@google.com>
Subject: Re: [PATCH] filemap: Remove PageHWPoison check from next_uptodate_page()
Date: Wed, 24 Nov 2021 00:11:13 +0000 [thread overview]
Message-ID: <20211124001113.GA2122045@hori.linux.bs1.fc.nec.co.jp> (raw)
In-Reply-To: <CAHbLzkpsUPJZmjRaGRFMq+YDb8eTOHYZfGbTpAOvDLEf-4Q5Jw@mail.gmail.com>
On Mon, Nov 22, 2021 at 11:28:10AM -0800, Yang Shi wrote:
> On Sat, Nov 20, 2021 at 9:44 AM Matthew Wilcox (Oracle)
> <willy@infradead.org> wrote:
> >
> > Pages are individually marked as suffering from hardware poisoning.
> > Checking that the head page is not hardware poisoned doesn't make
> > sense; we might be after a subpage. We check each page individually
> > before we use it, so this was an optimisation gone wrong.
>
> Yeah, it doesn't make too much sense to check the head page. And it
> seems the non-poisoned subpages could be PTE mapped instead of
> skipping the whole THP.
>
> Not sure if this is by design, it seems the hwpoisoned check in
> filemap_map_pages() does skip the subpages after the poisoned page. Or
> we should just skip the poisoned page itself? If so the below change
> may be needed:
>
> diff --git a/mm/filemap.c b/mm/filemap.c
> index daa0e23a6ee6..f1f0cb263b4a 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -3318,7 +3318,7 @@ vm_fault_t filemap_map_pages(struct vm_fault *vmf,
> do {
> page = find_subpage(head, xas.xa_index);
> if (PageHWPoison(page))
> - goto unlock;
> + goto skip;
>
> if (mmap_miss > 0)
> mmap_miss--;
> @@ -3337,6 +3337,7 @@ vm_fault_t filemap_map_pages(struct vm_fault *vmf,
> do_set_pte(vmf, page, addr);
> /* no need to invalidate: a not-present page won't be cached */
> update_mmu_cache(vma, addr, vmf->pte);
> +skip:
> unlock_page(head);
> continue;
> unlock:
first_map_page() or next_map_page() returns a page (if found) with
holding the refcount, and the new 'goto skip' path skips releasing it.
So this looks to me lead to the mismatch of refcount.
Could you explain the intention a little more (maybe related to your
recent patch about keeping hwpoison page in pagecache?) ?
Thanks,
Naoya Horiguchi
>
>
> >
> > Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> > ---
> > mm/filemap.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/mm/filemap.c b/mm/filemap.c
> > index 0b6f996108b4..65973204112d 100644
> > --- a/mm/filemap.c
> > +++ b/mm/filemap.c
> > @@ -3239,8 +3239,6 @@ static struct page *next_uptodate_page(struct page *page,
> > goto skip;
> > if (!PageUptodate(page) || PageReadahead(page))
> > goto skip;
> > - if (PageHWPoison(page))
> > - goto skip;
> > if (!trylock_page(page))
> > goto skip;
> > if (page->mapping != mapping)
> > --
> > 2.33.0
> >
next prev parent reply other threads:[~2021-11-24 0:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-20 17:44 Matthew Wilcox (Oracle)
2021-11-21 23:35 ` HORIGUCHI NAOYA(堀口 直也)
2021-11-22 19:28 ` Yang Shi
2021-11-24 0:11 ` HORIGUCHI NAOYA(堀口 直也) [this message]
2021-11-24 0:32 ` Yang Shi
2021-11-24 0:57 ` Yang Shi
2021-11-24 3:24 ` Andrew Morton
2021-11-25 14:51 ` Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211124001113.GA2122045@hori.linux.bs1.fc.nec.co.jp \
--to=naoya.horiguchi@nec.com \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-mm@kvack.org \
--cc=shy828301@gmail.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox