Linux-man Archive on
 help / color / Atom feed
From: "Li Xinhai" <>
To: "Michal Hocko" <>, akpm <>
Cc: "" <>,
	"Vlastimil Babka" <>,
	"" <>,
	"Linux API" <>,
	"Hugh Dickins" <>,
	linux-man <>
Subject: Re: [PATCH v2] mm: Fix checking unmapped holes for mbind
Date: Tue, 5 Nov 2019 10:29:41 +0800
Message-ID: <> (raw)
In-Reply-To: <>

On 2019-10-31 at 19:26 Michal Hocko wrote:
>On Wed 30-10-19 21:08:36, Andrew Morton wrote:
>> (cc
>> On Tue, 29 Oct 2019 17:56:06 +0800 "Li Xinhai" <> 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
>>        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")
>My understanding is that this really refers to area pointed to by nodemask.
>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?
>Michal Hocko
>SUSE Labs 

yes, mbind() care about the unmapped holes for non MPOL_DEFAULT cases, but 
other operations don't care those holes. It seems no clues about why that 
restriction was decided.

At present, if it is hard to decide to remove this restriction, we may keep the 
current behavior. New patch posted for this purpose,  
"[PATCH v3] mm: Fix checking unmapped holes for mbind".


      reply index

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2019-10-31  4:08 ` Andrew Morton
2019-10-31  6:01   ` Li Xinhai
2019-10-31 11:26   ` Michal Hocko
2019-11-05  2:29     ` Li Xinhai [this message]

Reply instructions:

You may reply publically 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-man Archive on

Archives are clonable:
	git clone --mirror linux-man/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-man linux-man/ \
	public-inbox-index linux-man

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone