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.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 73CFFCA9EC3 for ; Thu, 31 Oct 2019 04:08:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 11C2120859 for ; Thu, 31 Oct 2019 04:08:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="aLY8g0Ju" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 11C2120859 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 71F246B0003; Thu, 31 Oct 2019 00:08:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D0246B0005; Thu, 31 Oct 2019 00:08:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5E6156B0007; Thu, 31 Oct 2019 00:08:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0071.hostedemail.com [216.40.44.71]) by kanga.kvack.org (Postfix) with ESMTP id 3F9D46B0003 for ; Thu, 31 Oct 2019 00:08:39 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id A7F24181AC544 for ; Thu, 31 Oct 2019 04:08:38 +0000 (UTC) X-FDA: 76102748316.20.ring27_85a1b9999075e X-HE-Tag: ring27_85a1b9999075e X-Filterd-Recvd-Size: 3186 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf50.hostedemail.com (Postfix) with ESMTP for ; Thu, 31 Oct 2019 04:08:38 +0000 (UTC) Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A54C620859; Thu, 31 Oct 2019 04:08:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1572494917; bh=S7ZWRS5+YaKNt1ZrSgoOeGZ5/gjvA8XfW9lupuyOdjQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=aLY8g0Jui+5kmsZK4RQSjTJ9dR7W0t9sZShnderrSOwzvwVa0C8BIOBxtUdSfAi4J xQebDq0Gwg3kOG7PXV3YyZVNRen9jQdCx2F54K64YEJZog5Bcm6elmoAZBAF7T3THk mYicnjSxGysRcugJKpD5TQAG8H+eRi8GBiOeERrM= Date: Wed, 30 Oct 2019 21:08:36 -0700 From: Andrew Morton To: "Li Xinhai" Cc: "linux-mm@kvack.org" , Babka , Hocko , "linux-kernel@vger.kernel.org" , API , Dickins , linux-man@vger.kernel.org Subject: Re: [PATCH v2] mm: Fix checking unmapped holes for mbind Message-Id: <20191030210836.a17c0649354b59961903d1a8@linux-foundation.org> In-Reply-To: <201910291756045288126@gmail.com> References: <201910291756045288126@gmail.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: (cc linux-man@vger.kernel.org) On Tue, 29 Oct 2019 17:56:06 +0800 "Li Xinhai" wro= te: > queue_pages_range() will check for unmapped holes besides queue pages for > migration. The rules for checking unmapped holes are: > 1 Unmapped holes at any part of the specified range should be reported as > =A0 EFAULT if mbind() for none MPOL_DEFAULT cases; > 2 Unmapped holes at any part of the specified range should be ignored if > =A0 mbind() for MPOL_DEFAULT case; > Note that the second rule is the current implementation, but it seems > conflicts the Linux API definition. Can you quote the part of the API definition which you're looking at? My mbind(2) manpage says ERRORS EFAULT Part or all of the memory range specified by nodemask and max= n- ode points outside your accessible address space. Or, there = was an unmapped hole in the specified memory range specified by a= ddr and len. (I assume the first sentence meant to say "specified by addr and len") I agree with your interpretation, but there's no mention here that MPOL_DEFAULT is treated differently and I don't see why it should be. More broadly, I worry that it's too late to change this - existing applications might fail if we change the implementation in the proposed fashion. So perhaps what we should do here is to change the manpage to match reality? Is the current behavior causing you any problems in a real-world use case?