[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <68d332f9-290d-3537-1691-bb4805573f3f@linux.alibaba.com>
Date: Sat, 18 Jan 2020 21:47:22 -0800
From: Yang Shi <yang.shi@...ux.alibaba.com>
To: Wei Yang <richardw.yang@...ux.intel.com>
Cc: mhocko@...e.com, akpm@...ux-foundation.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] mm: move_pages: fix the return value if there are
not-migrated pages
On 1/18/20 6:57 PM, Wei Yang wrote:
> On Sun, Jan 19, 2020 at 10:37:20AM +0800, Wei Yang wrote:
>> On Sat, Jan 18, 2020 at 01:26:43PM +0800, Yang Shi wrote:
>>> The do_move_pages_to_node() might return > 0 value, the number of pages
>>> that are not migrated, then the value will be returned to userspace
>>> directly. But, move_pages() syscall would just return 0 or errno. So,
>>> we need reset the return value to 0 for such case as what pre-v4.17 did.
>>>
>>> Fixes: a49bd4d71637 ("mm, numa: rework do_pages_move")
>>> Cc: Michal Hocko <mhocko@...e.com>
>>> Cc: Wei Yang <richardw.yang@...ux.intel.com>
>>> Cc: <stable@...r.kernel.org> [4.17+]
>>> Signed-off-by: Yang Shi <yang.shi@...ux.alibaba.com>
>>> ---
>>> mm/migrate.c | 5 ++++-
>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/mm/migrate.c b/mm/migrate.c
>>> index 86873b6..3e75432 100644
>>> --- a/mm/migrate.c
>>> +++ b/mm/migrate.c
>>> @@ -1659,8 +1659,11 @@ static int do_pages_move(struct mm_struct *mm, nodemask_t task_nodes,
>>> goto out_flush;
>>>
>>> err = do_move_pages_to_node(mm, &pagelist, current_node);
>>> - if (err)
>>> + if (err) {
>>> + if (err > 0)
>>> + err = 0;
>>> goto out;
>>> + }
>>> if (i > start) {
>>> err = store_status(status, start, current_node, i - start);
>>> if (err)
>>> --
>>> 1.8.3.1
>>
>> Hey, I am afraid you missed something. There are three calls of
>> do_move_pages_to_node() in do_pages_move(). Why you just handle one return
>> value? How about the other two?
>>
> Well, current logic in do_pages_move() is a little complicated to read.
>
> I did a cleanup to make it easy to read and also friendly to do this fix.
>
> If they look good to you, you could rebase your fix on top of them.
Regression fix typically has higher priority. Since we already spotted
the regressions and proposed fixes, I'd suggest we fix them in 5.5-rc,
then aim any cleanup for 5.6 or 5.7. This should also make review easier
IMHO.
>
>> --
>> Wei Yang
>> Help you, Help me
Powered by blists - more mailing lists