linux-kernel - Re: [PATCH v2] mm: Fix checking unmapped holes for mbind

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2019103114005855855689@gmail.com>
Date:   Thu, 31 Oct 2019 14:01:00 +0800
From:   "Li Xinhai" <lixinhai.lxh@...il.com>
To:     akpm <akpm@...ux-foundation.org>
Cc:     "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "Vlastimil Babka" <vbabka@...e.cz>,
        "Michal Hocko" <mhocko@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Linux API" <linux-api@...r.kernel.org>,
        "Hugh Dickins" <hughd@...gle.com>,
        linux-man <linux-man@...r.kernel.org>,
        n-horiguchi <n-horiguchi@...jp.nec.com>
Subject: Re: [PATCH v2] mm: Fix checking unmapped holes for mbind

On 2019-10-31 at 12:08 Andrew Morton wrote:
>(cc linux-man@...r.kernel.org)
>
>On Tue, 29 Oct 2019 17:56:06 +0800 "Li Xinhai" <lixinhai.lxh@...il.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")
> 

this part: 
"Or, there was an unmapped hole in the specified memory range specified by addr 
and len."
is concerned by my patch.

>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.
> 
The first rule match the manpage, but the current mempolicy implementation only 
reports EFAULT if holes are within range, or at the head side of range. No EFAULT 
reported if hole at tail side of range. I suppose the first rule has to be fixed.

The seconde rule, when MPOL_DEFAULT is used, was summarized by me according 
to mempolicy implementation. Actually, this rule does not follow manpage and exsits 
for long days. In my understanding, this rule is reasonable (in code,  the internal flag 
MPOL_MF_DISCONTIG_OK is used for that purpose, there is comments for reason) 
and we'd better keep it.

>
>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?
> 
I prefer add description in manpage for the second rule, so no change to our code. 
Only fix for first rule.

>Is the current behavior causing you any problems in a real-world use
>case? 
I was using mbind() with MPOL_DEFAULT(or MPOL_BIND) to reset a range of address 
(which maybe contiguous or not in the whole range) to the default policy (to a specific 
node), and observed this issue. If mbind() call for each mapping one by one, we don't see the 
issue.

- Xinhai