From: Oscar Salvador <osalvador@suse.de>
To: Naoya Horiguchi <nao.horiguchi@gmail.com>
Cc: Muchun Song <songmuchun@bytedance.com>,
linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Mike Kravetz <mike.kravetz@oracle.com>,
Michal Hocko <mhocko@suse.com>, Tony Luck <tony.luck@intel.com>,
Naoya Horiguchi <naoya.horiguchi@nec.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/2] mm,hwpoison: make get_hwpoison_page call get_any_page()
Date: Wed, 12 May 2021 10:55:22 +0200 [thread overview]
Message-ID: <20210512085522.GB14726@linux> (raw)
In-Reply-To: <20210511151016.2310627-3-nao.horiguchi@gmail.com>
On Wed, May 12, 2021 at 12:10:16AM +0900, Naoya Horiguchi wrote:
> From: Naoya Horiguchi <naoya.horiguchi@nec.com>
>
> Now __get_hwpoison_page() could return -EBUSY in a race condition,
> so it's helpful to handle it by retrying. We already have retry
> logic, so make get_hwpoison_page() call get_any_page() when called
> from memory_failure().
As I stated in your previous patch, I think you should start returning -EBUSY
from this patch onwards.
> static int get_any_page(struct page *p, unsigned long flags)
> {
> int ret = 0, pass = 0;
> @@ -1152,50 +1136,76 @@ static int get_any_page(struct page *p, unsigned long flags)
> count_increased = true;
>
> try_again:
> - if (!count_increased && !__get_hwpoison_page(p)) {
> - if (page_count(p)) {
> - /* We raced with an allocation, retry. */
> - if (pass++ < 3)
> - goto try_again;
> - ret = -EBUSY;
> - } else if (!PageHuge(p) && !is_free_buddy_page(p)) {
> - /* We raced with put_page, retry. */
> - if (pass++ < 3)
> - goto try_again;
> - ret = -EIO;
> + if (!count_increased) {
> + ret = __get_hwpoison_page(p);
> + if (!ret) {
> + if (page_count(p)) {
> + /* We raced with an allocation, retry. */
> + if (pass++ < 3)
> + goto try_again;
> + ret = -EBUSY;
> + } else if (!PageHuge(p) && !is_free_buddy_page(p)) {
> + /* We raced with put_page, retry. */
> + if (pass++ < 3)
> + goto try_again;
> + ret = -EIO;
> + }
> + goto out;
> }
> + }
I think this can be improved.
We cannot have -EBUSY unless we come from __get_hwpoison_page() (!count_increased),
so I think a much more natural approach would be to stuff the hunk below in there,
and then place the other stuff in an else, so something like:
if (!count_increased) {
ret = __get_hwpoison_page(p);
if (!ret) {
if (page_count(p)) {
/* We raced with an allocation, retry. */
if (pass++ < 3)
goto try_again;
ret = -EBUSY;
} else if (!PageHuge(p) && !is_free_buddy_page(p)) {
/* We raced with put_page, retry. */
if (pass++ < 3)
goto try_again;
ret = -EIO;
}
goto out;
} else if (ret == -EBUSY) {
/* We raced with freeing huge page to buddy, retry. */
if (pass++ < 3)
goto try_again;
}
} else {
/* We do already have a refcount for this page, see if we can
* handle it.
*/
if (PageHuge(p) || PageLRU(p) || __PageMovable(p)) {
ret = 1;
} else {
/* A page we cannot handle. Check...
}
}
Other than that, looks good to me.
> +
> + if (ret == -EBUSY) {
> + /* We raced with freeing huge page to buddy, retry. */
> + if (pass++ < 3)
> + goto try_again;
--
Oscar Salvador
SUSE L3
next prev parent reply other threads:[~2021-05-12 8:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-11 15:10 [PATCH v3 0/2] hwpoison: fix race with compound page allocation Naoya Horiguchi
2021-05-11 15:10 ` [PATCH v3 1/2] mm,hwpoison: " Naoya Horiguchi
2021-05-12 8:33 ` Oscar Salvador
2021-05-13 0:00 ` HORIGUCHI NAOYA(堀口 直也)
2021-05-12 12:19 ` Michal Hocko
2021-05-12 23:51 ` HORIGUCHI NAOYA(堀口 直也)
2021-05-11 15:10 ` [PATCH v3 2/2] mm,hwpoison: make get_hwpoison_page call get_any_page() Naoya Horiguchi
2021-05-12 8:55 ` Oscar Salvador [this message]
2021-05-13 0:03 ` HORIGUCHI NAOYA(堀口 直也)
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=20210512085522.GB14726@linux \
--to=osalvador@suse.de \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=mike.kravetz@oracle.com \
--cc=nao.horiguchi@gmail.com \
--cc=naoya.horiguchi@nec.com \
--cc=songmuchun@bytedance.com \
--cc=tony.luck@intel.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;
as well as URLs for NNTP newsgroup(s).