Re: [PATCH] mm: redefine the MAP_SHARED_VALIDATE to other value

[zhong jiang <zhongjiang@huawei.com>]

On 2019/7/9 0:43, Michal Hocko wrote:
> On Mon 08-07-19 21:52:53, zhong jiang wrote:
>> On 2019/7/8 17:20, Michal Hocko wrote:
>>> [Cc Dan]
>>>
>>> On Mon 08-07-19 16:05:41, zhong jiang wrote:
>>>> As the mman manual says, mmap should return fails when we assign
>>>> the flags to MAP_SHARED | MAP_PRIVATE.
>>>>
>>>> But In fact, We run the code successfully and unexpected.
>>> What is the code that you are running and what is the code version.
>> Just an following code, For example,
>> addr = mmap(ADDR, PAGE_SIZE, PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_PRIVATE, fildes, OFFSET);
> Is this a real code that relies on the failure or merely a simple test
> to reflect the semantic you expect mmap to have?
>
>> We test it and works well in linux 4.19.   As the mmap manual says,  it should fails.
>>>> It is because MAP_SHARED_VALIDATE is introduced and equal to
>>>> MAP_SHARED | MAP_PRIVATE.
>>> This was a deliberate decision IIRC. Have a look at 1c9725974074 ("mm:
>>> introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap
>>> flags").
>> I  has seen the patch,  It introduce the issue.  but it only define the MAP_SHARED_VALIDATE incorrectly.
>> Maybe the author miss the condition that MAP_SHARED_VALIDATE is equal to MAP_PRIVATE | MAP_SHARE.
> No you are missing the point as Willy pointed out in a different email.
> This is intentional. No real application could have used the combination
> of two flags because it doesn't make any sense. And therefore the
> combination has been chosen to chnage the mmap semantic and check for
> valid mapping flags. LWN has a nice coverage[1].
Thanks you for pointing out.   I will look at the patch deeply.

Sincerely,
zhong jiang
>
> [1] https://lwn.net/Articles/758594/