linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Yang Shi <shy828301@gmail.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: "Linus Torvalds" <torvalds@linux-foundation.org>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Hugh Dickins" <hughd@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"HORIGUCHI NAOYA(堀口 直也)" <naoya.horiguchi@nec.com>,
	"Oscar Salvador" <osalvador@suse.de>,
	"Peter Xu" <peterx@redhat.com>,
	"Ajay Garg" <ajaygargnsit@gmail.com>,
	"Muchun Song" <songmuchun@bytedance.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Linux MM" <linux-mm@kvack.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: [UPDATE PATCH] mm: shmem: don't truncate page if memory failure happens
Date: Sun, 14 Nov 2021 08:54:36 -0800	[thread overview]
Message-ID: <CAHbLzkoMycvjVO_438JKB-Z7vW3UNmDKxaA3Hpj-zYX7MKkc0g@mail.gmail.com> (raw)
In-Reply-To: <YZErCLzSixIwTr6C@casper.infradead.org>

On Sun, Nov 14, 2021 at 7:28 AM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Sat, Nov 13, 2021 at 09:32:21PM -0800, Yang Shi wrote:
> > @@ -2466,7 +2467,18 @@ shmem_write_begin(struct file *file, struct address_space *mapping,
> >                       return -EPERM;
> >       }
> >
> > -     return shmem_getpage(inode, index, pagep, SGP_WRITE);
> > +     ret = shmem_getpage(inode, index, pagep, SGP_WRITE);
> > +
> > +     if (ret)
> > +             return ret;
> > +
> > +     if (*pagep && PageHWPoison(*pagep)) {
> > +             unlock_page(*pagep);
> > +             put_page(*pagep);
> > +             ret = -EIO;
>
> You definitely need to add:
>
>                 *pagep = NULL;

Thanks, will do it.

>
> I'm not entirely convinced that you need the conditional on '*pagep'.
> If we returned 0, there had better be a page at pagep!

For SGP_WRITE, yes, it has a page at pagep if ret is 0, but
shmem_getpage() could return 0 with NULL page at pagep for SGP_READ.

In the other thread that Linus elaborated why this commit was reverted
and needed some rework, the discussion about not relying on
implementation detail for error handling taught me it may be not a
robust implementation to assume it is never NULL.

We might refactor shmem_getpage() code in the future to make sure when
it returns success there must be a valid pagep so that we just need to
care about the return value for error handling.

>
> I also think this would be clearer if written as:
>
>         if (PageHWPoison(*pagep)) {
>                 unlock_page(*pagep);
>                 put_page(*pagep);
>                 *pagep = NULL;
>                 return -EIO;
>         }
>
>         return 0;
>
> instead of re-using ret.  Sometimes that can make the code flow clearer,
> but here, I don't think it does.

Sure.

>
> > @@ -4168,9 +4201,12 @@ struct page *shmem_read_mapping_page_gfp(struct address_space *mapping,
> >       error = shmem_getpage_gfp(inode, index, &page, SGP_CACHE,
> >                                 gfp, NULL, NULL, NULL);
> >       if (error)
> > -             page = ERR_PTR(error);
> > -     else
> > -             unlock_page(page);
> > +             return ERR_PTR(error);
> > +
> > +     unlock_page(page);
> > +     if (PageHWPoison(page))
> > +             return ERR_PTR(-EIO);
>
> Do we need to put_page() the page in this error case?

Aha, yes. Sorry for missing this. I was fooled by shmem_pin_map() in
i915 driver which does put page, but I realized it just puts the valid
pages pinned *before* meeting error page by second look
.
>


  reply	other threads:[~2021-11-14 16:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-14  5:32 Yang Shi
2021-11-14 15:28 ` Matthew Wilcox
2021-11-14 16:54   ` Yang Shi [this message]
2021-11-15 19:00     ` Yang Shi

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=CAHbLzkoMycvjVO_438JKB-Z7vW3UNmDKxaA3Hpj-zYX7MKkc0g@mail.gmail.com \
    --to=shy828301@gmail.com \
    --cc=ajaygargnsit@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=hughd@google.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=naoya.horiguchi@nec.com \
    --cc=osalvador@suse.de \
    --cc=peterx@redhat.com \
    --cc=songmuchun@bytedance.com \
    --cc=torvalds@linux-foundation.org \
    --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