linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: zhong jiang <zhongjiang@huawei.com>
Cc: akpm@linux-foundation.org, anshuman.khandual@arm.com,
	mst@redhat.com, linux-mm@kvack.org,
	Dan Williams <dan.j.williams@intel.com>
Subject: Re: [PATCH] mm: redefine the MAP_SHARED_VALIDATE to other value
Date: Mon, 8 Jul 2019 18:43:14 +0200	[thread overview]
Message-ID: <20190708164314.GE20617@dhcp22.suse.cz> (raw)
In-Reply-To: <5D234AB5.2070508@huawei.com>

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].


[1] https://lwn.net/Articles/758594/
-- 
Michal Hocko
SUSE Labs


  reply	other threads:[~2019-07-08 16:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-08  8:05 [PATCH] mm: redefine the MAP_SHARED_VALIDATE to other value zhong jiang
2019-07-08  9:20 ` Michal Hocko
2019-07-08 13:52   ` zhong jiang
2019-07-08 16:43     ` Michal Hocko [this message]
2019-07-09  1:52       ` zhong jiang
2019-07-08 14:43 ` Matthew Wilcox
2019-07-09  1:53   ` zhong jiang

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=20190708164314.GE20617@dhcp22.suse.cz \
    --to=mhocko@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=dan.j.williams@intel.com \
    --cc=linux-mm@kvack.org \
    --cc=mst@redhat.com \
    --cc=zhongjiang@huawei.com \
    /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).