From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 B33F7C43603 for ; Thu, 5 Dec 2019 00:43:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6D2162077B for ; Thu, 5 Dec 2019 00:43:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="nemYf06c" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6D2162077B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DE36D6B0D66; Wed, 4 Dec 2019 19:43:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D94416B0D67; Wed, 4 Dec 2019 19:43:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA9E56B0D68; Wed, 4 Dec 2019 19:43:41 -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 B5B746B0D66 for ; Wed, 4 Dec 2019 19:43:41 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 761018248D52 for ; Thu, 5 Dec 2019 00:43:41 +0000 (UTC) X-FDA: 76229239842.14.flame83_5a5df0cc88633 X-HE-Tag: flame83_5a5df0cc88633 X-Filterd-Recvd-Size: 5835 Received: from mail-ed1-f66.google.com (mail-ed1-f66.google.com [209.85.208.66]) by imf42.hostedemail.com (Postfix) with ESMTP for ; Thu, 5 Dec 2019 00:43:40 +0000 (UTC) Received: by mail-ed1-f66.google.com with SMTP id dc19so1089027edb.10 for ; Wed, 04 Dec 2019 16:43:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iaMy6XzXTeKRcbrmGhlvYZf9+gL+gS3pADrhzwtub+A=; b=nemYf06caIBoiOZQLBCzO5nD16RAUEAu2Tw6Kyo9wWZRjwqMeJBON603/KuSGmcXPq u6P9jTPSHRRJ+QLUHI2SXi7ILoH+Fqgec/CUmPTDrOiofJ+M2fZl1ocSRbvNCkvofWAo nNKwfO6wJ3QZWVVtZZToVYxf7B55ChYEP0kymfOg//k7raKjeRPIOb+kHEj9w7AjnCOC XgH2Pb3X2OzRoOR10MjKK8xahiiHCvm779J8V1fXXfZkwEwU2+oZZy7cc9/4nea8GQN/ TqqC+tromuZ3Eg7Fducs5aGmgBEpiRQcVUFcvbwayjYhFG0Azzv+OaIAaZzlAbFiau3L 1KaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iaMy6XzXTeKRcbrmGhlvYZf9+gL+gS3pADrhzwtub+A=; b=JvDHGPAEhf2P2YrSKX7yvxzAsZ9WbB9c8zmbLDZGIvC6UbU2axbM1K/eFHoy4ijdoM oXupVEQB+sjgW/zO2FGkkqSGAtbYjFMJ37iqVgFh2RnzaZNUW86mNkSBQLknWGRYjicm CDhkD+nbUJ3UIGM6tsZwlyKMdYmnO6Mec6dPJerKM3QDXXRs617xlOanyPzBfGBypjX/ HGD2m7It3LDNY5jgSlSf9vwHuiG3UDV4aFRKCATHq5jyYvGZh8p7lLCGFl/0rO0okJMo kMuSr5vuUfPWoRUQ5i33g+bwwkXeMYmDq35HDtePyuiEoLn67aG5SXFCQTX/199C9EvT FmUQ== X-Gm-Message-State: APjAAAXZRmtRPNKeTwyQRSXIjddOnE4CgMG3F/xNqcHmcvm5A2PcKZnq mtBpAJ/a02jeCLnuYcvbK0K7rgEIqGvQHJsgerY= X-Google-Smtp-Source: APXvYqwv64ZXwIybkEcuiCmbC875Vz31KOQHexj9Sx9HRxICA3ZTUW6T6cECcsVKiO8rYUpJoTMZeagsGrN0ajG1HhE= X-Received: by 2002:a05:6402:518:: with SMTP id m24mr7492160edv.35.1575506619800; Wed, 04 Dec 2019 16:43:39 -0800 (PST) MIME-Version: 1.0 References: <1a8ccccb-e429-45d3-3615-b3b8bf04c6fe@nvidia.com> <894a7d96-b715-bec5-2f72-1552891672ff@nvidia.com> In-Reply-To: <894a7d96-b715-bec5-2f72-1552891672ff@nvidia.com> From: Yang Shi Date: Wed, 4 Dec 2019 16:43:29 -0800 Message-ID: Subject: Re: bug: move_pages(2) does not udpate "status" if no pages are moved To: John Hubbard , Christoph Lameter Cc: Felix Abecassis , Linux MM , Andrew Morton Content-Type: text/plain; charset="UTF-8" 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: On Wed, Dec 4, 2019 at 3:45 PM John Hubbard wrote: > > On 12/4/19 12:04 PM, Yang Shi wrote: > > On Wed, Dec 4, 2019 at 11:21 AM John Hubbard wrote: > >> > >> On 12/4/19 11:01 AM, Felix Abecassis wrote: > >>> Hello all, > >>> > >> > >> 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 values > >>> (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 any > >> of the pages. So the pages are where you requested them to end up. > > > > I don't think we can just simply return all zeros here. It looks the > > status should contain error code or the target node id if the page is > > moved to that node successfully. So, if the page is already on the > > requested node, the status should contain the current node id, but the > > current node maybe not 0. > > > > So, IMHO it sounds like a valid bug. > > > > Yes, you're right, a more precise reading of the man page does support that: > if move_pages() returns 0, then the status array *must* contain valid node IDs. > I see. (Felix also mentioned the same thing, in a side note.) > > Looking some more at both the man page and Felix's report (and the kernel > implementation), it seems like there are maybe two bugs here: > > 1) Not setting the status array in some cases, if some pages were not moved for > "non fatal" reasons, and > > 2) Returning success if no pages were moved. The "ERRORS" section of the man > page seems to require that ENOENT be returned in that case. Although, you could > perhaps argue that this statement is only unidirectional. In other words, maybe > ENOENT happens, but it doesn't *have* to happen, if all pages were already on the > target node. > > ERRORS > > ENOENT No pages were found that require moving. All pages are either already > on the target node, not present, had an invalid address or could not > be moved because they were mapped by multiple processes. Thanks for pointing this out. Yes, the man page says so, but the code doesn't do so at all. I dig into the very first commit 742755a1d8ce2b548428f7aacf1758b4bba50080 ("[PATCH] page migration: sys_move_pages(): support moving of individual pages"), however, it didn't return -ENOENT if the pages are already on the target node if I read the code correctly. Added Chris in this thread who is the original author of this API. > > > thanks, > -- > John Hubbard > NVIDIA