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 73B09C43603 for ; Wed, 4 Dec 2019 20:04:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 15D7A2073B for ; Wed, 4 Dec 2019 20:04:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="WKos5bTG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 15D7A2073B 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 783956B0C4F; Wed, 4 Dec 2019 15:04:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7338D6B0C50; Wed, 4 Dec 2019 15:04:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 648F56B0C51; Wed, 4 Dec 2019 15:04:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0133.hostedemail.com [216.40.44.133]) by kanga.kvack.org (Postfix) with ESMTP id 4EFCD6B0C4F for ; Wed, 4 Dec 2019 15:04:31 -0500 (EST) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 0AEC3180AD807 for ; Wed, 4 Dec 2019 20:04:31 +0000 (UTC) X-FDA: 76228536342.01.unit64_7eae93e825a63 X-HE-Tag: unit64_7eae93e825a63 X-Filterd-Recvd-Size: 5048 Received: from mail-ed1-f66.google.com (mail-ed1-f66.google.com [209.85.208.66]) by imf45.hostedemail.com (Postfix) with ESMTP for ; Wed, 4 Dec 2019 20:04:30 +0000 (UTC) Received: by mail-ed1-f66.google.com with SMTP id cy15so535765edb.4 for ; Wed, 04 Dec 2019 12:04:30 -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=Syh5s4D3nIr8Pcofuy6t+kx8EPPevAQ8qxQo+Ptq5C0=; b=WKos5bTGCFQou0hihCzyr2Kwz4zQAK0WlmTypV7LNnqk8lKL/L6gwqllCcurJ/rLlF qpIyuYW7aaVRYj9PzU8tbZLiiLhDE5IKARU8Dsc9pO+TGCfCH5bGmVhCinSxW7SN9j1w 1vN5a85C1KxLFQjRYgv7Y3AUFHHdVnzg6WXZc0jV1fS6Eb1XcCSLhpg6qXoMsAzHK7ru CIYx1+bjefiqZAb1NxFfmAwzhz3hu4zT8F6CeyH3+NA+bfnD31ZqTo6lUvdaHALbuvLA TlZq7VoQHIvZJDP2OGNrJy1HGsGvFj9KB/iKlEoVWiHzSnRL9pUlfE979mAz1PdsM1bX Po3Q== 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=Syh5s4D3nIr8Pcofuy6t+kx8EPPevAQ8qxQo+Ptq5C0=; b=fDn4uRZnh90qjI4V5bxy7uS6h+UI01M2HC1IzY9MdkCNjG68sVzPqb37Kt6cfssojW 4NcFhKp9n/0036Q3uNnTXyfAcrbKFV3TbX4fflcTU4rn/+QDXliq940IBYPMrmVrhwpf Epdy0pM/2ixGb4N7+Frjs3BIIySfqge0LGRGDVEmLLs0Tspwau0fcs/eIOHei4xYmRJG KeZhq8tFY2L+9ddEjy3w968ZO1uyTV/PTaRrNUwCmNh8DL29v3yYC0YmW2G8VLw9ZSNE ogjGnqit6Q16RLgUWRBokaG1sIf5/lAf4d8wXIEmJF7B9BzGxhSmJ4BE1+57/vvHDG3B ee3w== X-Gm-Message-State: APjAAAXuyS1zutq6NWsDif7BK0f+Z4hZ9ISByW1PxH+kyIIi4S+o898B 63HOWEjZuDW5J4t1fvYmeQZZw8PcjUs6mem5w+Q= X-Google-Smtp-Source: APXvYqz9MStKzs9QPaXn+ufZxnoxXNGKZDL6VzDXxa1noIWkTZBtU9X8+snBewjoDOFoI9YJu5/T3mBV2Es3rCVDaWU= X-Received: by 2002:a05:6402:31ba:: with SMTP id dj26mr6071845edb.189.1575489869150; Wed, 04 Dec 2019 12:04:29 -0800 (PST) MIME-Version: 1.0 References: <1a8ccccb-e429-45d3-3615-b3b8bf04c6fe@nvidia.com> In-Reply-To: <1a8ccccb-e429-45d3-3615-b3b8bf04c6fe@nvidia.com> From: Yang Shi Date: Wed, 4 Dec 2019 12:04:16 -0800 Message-ID: Subject: Re: bug: move_pages(2) does not udpate "status" if no pages are moved To: John Hubbard 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 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. > > > > > > Looking at the kernel code, we are probably exiting do_pages_move here: > > out_flush: > > if (list_empty(&pagelist)) > > return err; > > > I looked at that code and the surrounding function, and it's been pretty much > unchanged for quite a while. The above was last touched in April, 2018, for > example. > > Yes, we could change the kernel code to fill in the array with zeroes in that > situation, but the man page doesn't actually cover this case at all. We'd have > to also change the man page, to say something like, "if pages were not moved > because they were already in the requested location, then the status array > will contain for such pages". In other words, the kernel matches > 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 want > to weigh in there? > > > thanks, > -- > John Hubbard > NVIDIA >