From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=2Hla=Z2=kvack.org=owner-linux-mm@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no
	version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id A16F7C43603
	for <linux-mm@archiver.kernel.org>; Wed,  4 Dec 2019 19:21:41 +0000 (UTC)
Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17])
	by mail.kernel.org (Postfix) with ESMTP id 57D3F20675
	for <linux-mm@archiver.kernel.org>; Wed,  4 Dec 2019 19:21:41 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=pass (2048-bit key) header.d=nvidia.com header.i=@nvidia.com header.b="CnPnB/gy"
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 57D3F20675
Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=nvidia.com
Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org
Received: by kanga.kvack.org (Postfix)
	id E593F6B0C26; Wed,  4 Dec 2019 14:21:40 -0500 (EST)
Received: by kanga.kvack.org (Postfix, from userid 40)
	id DE3816B0C27; Wed,  4 Dec 2019 14:21:40 -0500 (EST)
X-Delivered-To: int-list-linux-mm@kvack.org
Received: by kanga.kvack.org (Postfix, from userid 63042)
	id CAB696B0C28; Wed,  4 Dec 2019 14:21:40 -0500 (EST)
X-Delivered-To: linux-mm@kvack.org
Received: from forelay.hostedemail.com (smtprelay0214.hostedemail.com [216.40.44.214])
	by kanga.kvack.org (Postfix) with ESMTP id B03D16B0C26
	for <linux-mm@kvack.org>; Wed,  4 Dec 2019 14:21:40 -0500 (EST)
Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251])
	by forelay01.hostedemail.com (Postfix) with SMTP id 53B5A180AD811
	for <linux-mm@kvack.org>; Wed,  4 Dec 2019 19:21:40 +0000 (UTC)
X-FDA: 76228428360.09.mice19_2ba4c76416843
X-HE-Tag: mice19_2ba4c76416843
X-Filterd-Recvd-Size: 4364
Received: from hqnvemgate24.nvidia.com (hqnvemgate24.nvidia.com [216.228.121.143])
	by imf03.hostedemail.com (Postfix) with ESMTP
	for <linux-mm@kvack.org>; Wed,  4 Dec 2019 19:21:39 +0000 (UTC)
Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate24.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA)
	id <B5de807330000>; Wed, 04 Dec 2019 11:21:23 -0800
Received: from hqmail.nvidia.com ([172.20.161.6])
  by hqpgpgate101.nvidia.com (PGP Universal service);
  Wed, 04 Dec 2019 11:21:38 -0800
X-PGP-Universal: processed;
	by hqpgpgate101.nvidia.com on Wed, 04 Dec 2019 11:21:38 -0800
Received: from [10.110.48.28] (10.124.1.5) by HQMAIL107.nvidia.com
 (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 4 Dec
 2019 19:21:37 +0000
Subject: Re: bug: move_pages(2) does not udpate "status" if no pages are moved
To: Felix Abecassis <fabecassis@nvidia.com>, <linux-mm@kvack.org>
CC: Andrew Morton <akpm@linux-foundation.org>
References: <f95aae1d-0328-7beb-2130-4f59ba38abf1@nvidia.com>
X-Nvconfidentiality: public
From: John Hubbard <jhubbard@nvidia.com>
Message-ID: <1a8ccccb-e429-45d3-3615-b3b8bf04c6fe@nvidia.com>
Date: Wed, 4 Dec 2019 11:21:37 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <f95aae1d-0328-7beb-2130-4f59ba38abf1@nvidia.com>
X-Originating-IP: [10.124.1.5]
X-ClientProxiedBy: HQMAIL111.nvidia.com (172.20.187.18) To
 HQMAIL107.nvidia.com (172.20.187.13)
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1;
	t=1575487283; bh=fdyuMiKi2MWjgk+jlxdPTyRhAgb7Rb7j+GgScZEdhsk=;
	h=X-PGP-Universal:Subject:To:CC:References:X-Nvconfidentiality:From:
	 Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:
	 X-Originating-IP:X-ClientProxiedBy:Content-Type:Content-Language:
	 Content-Transfer-Encoding;
	b=CnPnB/gynwK8Ew6zIvG8+Zcd86zZ8Bz2T8Okw192rsGAv96mQvBA/GZhE8XA9eD2n
	 3f0cQ41CNltGZDGJQEda1v1GJT/qdGHJyZDFLMcIXVTG2/iROjjhUlNlgewV0RB9oh
	 rOZ0nE6MJoxWEHIMdhe5w8Do/ITFX4y3Bd2eYqTBtCatjWg/kf18o6hlNq4zNo/p1i
	 rBdSC/vYDBS8D+q13zivTpbexczid9f7L5QVeLj00S9QwgzfEFvTUA+9Oyrok9QKXY
	 n52vIHIvR+duujwlJGiLlttjnDJBs4GTKRO7AH3bc1wrf3LeiqXQCK1w1BZI5DtmHV
	 IS0smV7NJcLGw==
X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4
Sender: owner-linux-mm@kvack.org
Precedence: bulk
X-Loop: owner-majordomo@kvack.org
List-ID: <linux-mm.kvack.org>

On 12/4/19 11:01 AM, Felix Abecassis wrote:
> Hello all,
>=20

Hi Felix,

Thanks for writing up a very clear description of the problem.

> On kernel 5.3, when using the move_pages syscall (wrapped by libnuma) and=
 all
> pages happen to be on the right node already, this function returns 0 but=
 the
> "status" array is not updated. This array potentially contains garbage va=
lues
> (e.g. from malloc(3)), and I don't see a way to detect this.


The way to detect this case would be to zero the array before calling move_=
pages().
Then, if move_pages() returns 0, and the array remains full of zeroes, you =
can
conclude that move_pages() "succeeded", and that there were no errors for a=
ny
of the pages. So the pages are where you requested them to end up.


>=20
> Looking at the kernel code, we are probably exiting do_pages_move here:
> out_flush:
> =C2=A0=C2=A0=C2=A0 if (list_empty(&pagelist))
> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 return err;


I looked at that code and the surrounding function, and it's been pretty mu=
ch
unchanged for quite a while. The above was last touched in April, 2018, for=
=20
example.

Yes, we could change the kernel code to fill in the array with zeroes in th=
at
situation, but the man page doesn't actually cover this case at all. We'd h=
ave
to also change the man page, to say something like, "if pages were not move=
d=20
because they were already in the requested location, then the status array
will contain <SOME_VALUE> for such pages". In other words, the kernel match=
es
the requirements (the man page) as it stands today, at least as I'm reading=
 it.

And given that one can already figure all this out with the existing kernel
and libnuma behavior, I'm guessing that the linux-mm folks will not see any
reason to make such a change--but maybe I'm guessing wrong. Anyone on CC wa=
nt
to weigh in there?


thanks,
--=20
John Hubbard
NVIDIA