linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "yaoaili [么爱利]" <yaoaili@kingsoft.com>
To: "HORIGUCHI NAOYA(堀口 直也)" <naoya.horiguchi@nec.com>,
	"Oscar Salvador" <osalvador@suse.de>
Cc: "yaoaili126@163.com" <yaoaili126@163.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"YANGFENG1 [杨峰]" <YANGFENG1@kingsoft.com>,
	"willy@infradead.org" <willy@infradead.org>
Subject: RE: [PATCH] Fix incorrect compound page flags store
Date: Tue, 8 Sep 2020 08:48:21 +0000	[thread overview]
Message-ID: <d887264d97c24f8ebd7aa3b34b189f19@kingsoft.com> (raw)
In-Reply-To: <20200908083630.GA15481@hori.linux.bs1.fc.nec.co.jp>

Does the if (PageCompound(p) && compound_head(p) != orig_head) check cover the case you mentioned?
Thanks

-----Original Message-----
From: HORIGUCHI NAOYA(堀口 直也) [mailto:naoya.horiguchi@nec.com] 
Sent: Tuesday, September 8, 2020 4:37 PM
To: Oscar Salvador <osalvador@suse.de>
Cc: yaoaili126@163.com; linux-mm@kvack.org; YANGFENG1 [杨峰] <YANGFENG1@kingsoft.com>; yaoaili [么爱利] <yaoaili@kingsoft.com>; willy@infradead.org
Subject: Re: [PATCH] Fix incorrect compound page flags store

On Tue, Sep 08, 2020 at 09:26:13AM +0200, Oscar Salvador wrote:
> On Tue, Sep 08, 2020 at 07:02:12AM +0000, HORIGUCHI NAOYA(堀口 直也) wrote:
> > On Mon, Sep 07, 2020 at 08:44:42PM -0700, yaoaili126@163.com wrote:
> > > From: Aili Yao <yaoaili@kingsoft.com>
> > >
> > > PageHuge(p) branch will never be true,but for compound page we need to set page_flags to correct value.
> > >
> > > Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> > > Signed-off-by: Yang Feng < yangfeng1@kingsoft.com>
> > > Signed-off-by: Aili Yao <yaoaili@kingsoft.com>
> >
> > I found that this PageHuge() check is removed and no long exists in 
> > the latest mmotm, so we don't have worry about it.
>
> I might be missing something, so bear with me.
>
> It is true that the PageHuge check is gone, but we are storing the 
> page's flags in page_flags, even if the page is a tail (e.g: part of a 
> compound page ).
> Should not we store heads' flags instead?

I think that saving ->flags of the raw error page is OK, because even in thp case we focus on the raw page instead of its head page from memory error perspective.  It's not assumed that we can contain the error thp in the thp unit and instead we always rely on thp split. (For hugetlb, we now contain the errored hugetlb in hugetlb unit, so saving its head page might be OK.)

Theoretically, it could happen that a error could be collapsed into a new thp just after passing over the following block:

  1408          if (PageTransHuge(hpage)) {
  1409                  if (try_to_split_thp_page(p, "Memory Failure") < 0) {
  1410                          action_result(pfn, MF_MSG_UNSPLIT_THP, MF_IGNORED);
  1411                          return -EBUSY;
  1412                  }
  1413                  VM_BUG_ON_PAGE(!page_count(p), p);
  1414          }

So I feel that some check might be added after holding page lock to avoid that case. Or acutally, it might better that moving the above block into page lock is more better for simpler code.

Thanks,
Naoya Horiguchi

> AFAICS, hpage contains either the head of the compound page, or the 
> page itself in case it is a normal page.
>
> --
> Oscar Salvador
> SUSE L3
>

  reply	other threads:[~2020-09-08  8:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-08  3:44 yaoaili126
2020-09-08  7:02 ` HORIGUCHI NAOYA(堀口 直也)
2020-09-08  7:18   ` yaoaili [么爱利]
2020-09-08  7:26   ` Oscar Salvador
2020-09-08  8:02     ` yaoaili [么爱利]
2020-09-08  8:09       ` Oscar Salvador
2020-09-08  8:36     ` HORIGUCHI NAOYA(堀口 直也)
2020-09-08  8:48       ` yaoaili [么爱利] [this message]
2020-09-08  9:00         ` HORIGUCHI NAOYA(堀口 直也)
2020-09-08  9:10           ` yaoaili [么爱利]
2020-09-08  8:51       ` Oscar Salvador
2020-09-08  9:05         ` HORIGUCHI NAOYA(堀口 直也)
2020-09-18  9:35           ` Oscar Salvador
2020-09-25  1:18             ` HORIGUCHI NAOYA(堀口 直也)
2020-09-25  1:55               ` yaoaili [么爱利]
2020-09-25  4:35                 ` HORIGUCHI NAOYA(堀口 直也)
2020-09-25  5:52                   ` yaoaili [么爱利]
  -- strict thread matches above, loose matches on Subject: below --
2020-09-02 11:24 [PATCH] fix " yaoaili [么爱利]
2020-09-02 11:35 ` 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=d887264d97c24f8ebd7aa3b34b189f19@kingsoft.com \
    --to=yaoaili@kingsoft.com \
    --cc=YANGFENG1@kingsoft.com \
    --cc=linux-mm@kvack.org \
    --cc=naoya.horiguchi@nec.com \
    --cc=osalvador@suse.de \
    --cc=willy@infradead.org \
    --cc=yaoaili126@163.com \
    /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