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 0D417CA9ECE for ; Thu, 31 Oct 2019 04:08:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D8AAD20859 for ; Thu, 31 Oct 2019 04:08:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1572494920; bh=S7ZWRS5+YaKNt1ZrSgoOeGZ5/gjvA8XfW9lupuyOdjQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=rQlRc2m9eeIZGB+xjv8w3Q9qw0qDPvNzhLNrif7pqYrF654uzY2TFMim/DJvetcMC jqC2MlGiFY8Plx7vI40LVro5p1ItYo3GJnFVuyiHoF+g+JWyZ1YgVn+bcTwv6bukIZ HM8IC2WPvG3rz6jWAGdyVsEiR9edRcyNyliIAsLw= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726524AbfJaEIi (ORCPT ); Thu, 31 Oct 2019 00:08:38 -0400 Received: from mail.kernel.org ([198.145.29.99]:55576 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726127AbfJaEIi (ORCPT ); Thu, 31 Oct 2019 00:08:38 -0400 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 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org (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?