From: Davide Libenzi <davidel@xmailserver.org>
To: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Joern Engel <joern@logfs.org>, Jianguo Wu <wujianguo@huawei.com>,
Eric B Munson <emunson@akamai.com>,
David Rientjes <rientjes@google.com>,
linux-mm@kvack.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [patch][resend] MAP_HUGETLB munmap fails with size not 2MB aligned
Date: Wed, 25 Mar 2015 18:06:51 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.10.1503251754320.26501@davide-lnx3> (raw)
In-Reply-To: <alpine.LSU.2.11.1503251708530.5592@eggly.anvils>
On Wed, 25 Mar 2015, Hugh Dickins wrote:
> When you say "tracking back to 3.2.x", I think you mean you've tried as
> far back as 3.2.x and found the same behaviour, but not tried further?
>
> From the source, it looks like this is unchanged since MAP_HUGETLB was
> introduced in 2.6.32. And is the same behaviour as you've been given
> with hugetlbfs since it arrived in 2.5.46.
Went back checking the application logs, an I had to patch the code (the
application one - to align size on munmap()) on May 2014.
But it might be we started noticing it at that time, because before the
allocation pattern was simply monotonic, so it could be it was always
there.
The bug test app is ten lines of code, to verify that.
> The patch looks to me as if it will do what you want, and I agree
> that it's displeasing that you can mmap a size, and then fail to
> munmap that same size.
>
> But I tend to think that's simply typical of the clunkiness we offer
> you with hugetlbfs and MAP_HUGETLB: that it would have been better to
> make a different choice all those years ago, but wrong to change the
> user interface now.
>
> Perhaps others will disagree. And if I'm wrong, and the behaviour
> got somehow changed in 3.2, then that's a different story and we
> should fix it back.
This is not an interface change, in the sense old clients will continue to
work.
This is simply respecting the mmap(2) POSIX specification, for a feature
which has been exposed via mmap(2).
- Davide
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-03-26 1:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-23 2:26 Davide Libenzi
2015-03-26 0:47 ` Hugh Dickins
2015-03-26 1:06 ` Davide Libenzi [this message]
2015-03-26 3:17 ` David Rientjes
2015-03-26 11:56 ` Davide Libenzi
2015-03-26 14:08 ` Eric B Munson
2015-03-30 16:03 ` KOSAKI Motohiro
2015-03-30 20:32 ` Hugh Dickins
2015-03-26 19:15 ` David Rientjes
2015-03-26 19:39 ` Davide Libenzi
2015-03-26 20:03 ` David Rientjes
2015-03-27 9:47 ` Vlastimil Babka
2015-03-27 13:51 ` Eric B Munson
2015-03-27 9:45 ` Vlastimil Babka
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=alpine.DEB.2.10.1503251754320.26501@davide-lnx3 \
--to=davidel@xmailserver.org \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=emunson@akamai.com \
--cc=hughd@google.com \
--cc=joern@logfs.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
--cc=wujianguo@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