From: Andrew Morton <akpm@linux-foundation.org>
To: "Li Xinhai" <lixinhai.lxh@gmail.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>, Babka <vbabka@suse.cz>,
Hocko <mhocko@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
API <linux-api@vger.kernel.org>, Dickins <hughd@google.com>,
linux-man@vger.kernel.org
Subject: Re: [PATCH v2] mm: Fix checking unmapped holes for mbind
Date: Wed, 30 Oct 2019 21:08:36 -0700 [thread overview]
Message-ID: <20191030210836.a17c0649354b59961903d1a8@linux-foundation.org> (raw)
In-Reply-To: <201910291756045288126@gmail.com>
(cc linux-man@vger.kernel.org)
On Tue, 29 Oct 2019 17:56:06 +0800 "Li Xinhai" <lixinhai.lxh@gmail.com> wrote:
> 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
> EFAULT if mbind() for none MPOL_DEFAULT cases;
> 2 Unmapped holes at any part of the specified range should be ignored if
> 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 maxn-
ode points outside your accessible address space. Or, there was
an unmapped hole in the specified memory range specified by addr
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?
next parent reply other threads:[~2019-10-31 4:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <201910291756045288126@gmail.com>
2019-10-31 4:08 ` Andrew Morton [this message]
2019-10-31 6:01 ` [PATCH v2] mm: Fix checking unmapped holes for mbind Li Xinhai
2019-10-31 11:26 ` Michal Hocko
2019-11-05 2:29 ` Li Xinhai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191030210836.a17c0649354b59961903d1a8@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lixinhai.lxh@gmail.com \
--cc=mhocko@kernel.org \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).