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=-2.5 required=3.0 tests=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 664EECA9EC3 for ; Thu, 31 Oct 2019 11:26:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0EFBC20650 for ; Thu, 31 Oct 2019 11:26:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0EFBC20650 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6E59E6B0003; Thu, 31 Oct 2019 07:26:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6962A6B0005; Thu, 31 Oct 2019 07:26:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 58E696B0007; Thu, 31 Oct 2019 07:26:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0125.hostedemail.com [216.40.44.125]) by kanga.kvack.org (Postfix) with ESMTP id 368E56B0003 for ; Thu, 31 Oct 2019 07:26:13 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id CCE1C5DFD for ; Thu, 31 Oct 2019 11:26:12 +0000 (UTC) X-FDA: 76103850984.27.move59_19164fdcc1e02 X-HE-Tag: move59_19164fdcc1e02 X-Filterd-Recvd-Size: 3059 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Thu, 31 Oct 2019 11:26:12 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 8C7B6B5F1; Thu, 31 Oct 2019 11:26:10 +0000 (UTC) Date: Thu, 31 Oct 2019 12:26:09 +0100 From: Michal Hocko To: Andrew Morton Cc: Li Xinhai , "linux-mm@kvack.org" , Babka , "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: <20191031112609.GG13102@dhcp22.suse.cz> References: <201910291756045288126@gmail.com> <20191030210836.a17c0649354b59961903d1a8@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20191030210836.a17c0649354b59961903d1a8@linux-foundation.org> User-Agent: Mutt/1.10.1 (2018-07-13) 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: On Wed 30-10-19 21:08:36, Andrew Morton wrote: > (cc linux-man@vger.kernel.org) >=20 > On Tue, 29 Oct 2019 17:56:06 +0800 "Li Xinhai" = wrote: >=20 > > 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 reporte= d 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. >=20 > Can you quote the part of the API definition which you're looking at? >=20 > My mbind(2) manpage says >=20 > ERRORS > EFAULT Part or all of the memory range specified by nodemask and= maxn- > ode points outside your accessible address space. Or, th= ere was > an unmapped hole in the specified memory range specified = by addr > and len. >=20 > (I assume the first sentence meant to say "specified by addr and len") My understanding is that this really refers to area pointed to by nodemas= k. Btw. why there is any special casing around the unmapped holes with the address space range? This looks like an antipattern to other address space operations to me. E.g. munmap simply unmaps all existing vmas in the given range, mprotect, madvise etc. behave the same. So my question is, do we want to remove that weird restriction and simply act on all existing VMAs in the range? The only situation this could regress would be if somebody used mbind to probe for existing VMAs and that sounds a more than sensible to me. Or am I missing anything? --=20 Michal Hocko SUSE Labs