From: Michal Hocko <mhocko@suse.com>
To: p.jaroszynski@gmail.com
Cc: linux-mm@kvack.org, Piotr Jaroszynski <pjaroszynski@nvidia.com>,
Jan Stancek <jstancek@redhat.com>
Subject: Re: [PATCH] Fix do_move_pages_to_node() error handling
Date: Wed, 14 Nov 2018 08:34:15 +0100 [thread overview]
Message-ID: <20181114073415.GD23419@dhcp22.suse.cz> (raw)
In-Reply-To: <20181114004059.1287439-1-pjaroszynski@nvidia.com>
On Tue 13-11-18 16:40:59, p.jaroszynski@gmail.com wrote:
> From: Piotr Jaroszynski <pjaroszynski@nvidia.com>
>
> migrate_pages() can return the number of pages that failed to migrate
> instead of 0 or an error code. If that happens, the positive return is
> treated as an error all the way up through the stack leading to the
> move_pages() syscall returning a positive number. I believe this
> regressed with commit a49bd4d71637 ("mm, numa: rework do_pages_move")
> that refactored a lot of this code.
Yes this is correct.
> Fix this by treating positive returns as success in
> do_move_pages_to_node() as that seems to most closely follow the
> previous code. This still leaves the question whether silently
> considering this case a success is the right thing to do as even the
> status of the pages will be set as if they were successfully migrated,
> but that seems to have been the case before as well.
Yes, I believe the previous semantic was just wrong and we want to fix
it. Jan has already brought this up [1]. I believe we want to update the
documentation rather than restore the previous hazy semantic.
Just wondering, how have you found out? Is there any real application
failing because of the change or this is a result of some test?
[1] http://lkml.kernel.org/r/0329efa0984b9b0252ef166abb4498c0795fab36.1535113317.git.jstancek@redhat.com
>
> Fixes: a49bd4d71637 ("mm, numa: rework do_pages_move")
> Signed-off-by: Piotr Jaroszynski <pjaroszynski@nvidia.com>
> ---
> mm/migrate.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 8baeb7ff2f6d..b42efef780d6 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -1461,6 +1461,7 @@ static int store_status(int __user *status, int start, int value, int nr)
> return 0;
> }
>
> +/* Returns 0 or an error code. */
> static int do_move_pages_to_node(struct mm_struct *mm,
> struct list_head *pagelist, int node)
> {
> @@ -1473,6 +1474,15 @@ static int do_move_pages_to_node(struct mm_struct *mm,
> MIGRATE_SYNC, MR_SYSCALL);
> if (err)
> putback_movable_pages(pagelist);
> +
> + /*
> + * migrate_pages() can return the number of not migrated pages, but the
> + * callers of do_move_pages_to_node() only care about and handle hard
> + * failures.
> + */
> + if (err > 0)
> + err = 0;
> +
> return err;
> }
>
> --
> 2.11.0.262.g4b0a5b2.dirty
>
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2018-11-14 7:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-14 0:40 [PATCH] Fix do_move_pages_to_node() error handling p.jaroszynski
2018-11-14 7:34 ` Michal Hocko [this message]
2018-11-14 11:29 ` Michal Hocko
2018-11-14 18:04 ` Piotr Jaroszynski
2018-11-14 21:22 ` Michal Hocko
2018-11-15 1:04 ` Piotr Jaroszynski
2018-11-15 8:47 ` Michal Hocko
2018-11-15 18:58 ` Piotr Jaroszynski
2018-11-16 11:49 ` Michal Hocko
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=20181114073415.GD23419@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=jstancek@redhat.com \
--cc=linux-mm@kvack.org \
--cc=p.jaroszynski@gmail.com \
--cc=pjaroszynski@nvidia.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).