From: Vlastimil Babka <vbabka@suse.cz>
To: Davide Libenzi <davidel@xmailserver.org>,
David Rientjes <rientjes@google.com>
Cc: Hugh Dickins <hughd@google.com>,
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>,
linux-mm@kvack.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-man@vger.kernel.org, Linux API <linux-api@vger.kernel.org>,
Michael Kerrisk <mtk.manpages@gmail.com>
Subject: Re: [patch][resend] MAP_HUGETLB munmap fails with size not 2MB aligned
Date: Fri, 27 Mar 2015 10:45:44 +0100 [thread overview]
Message-ID: <551526C8.1000105@suse.cz> (raw)
In-Reply-To: <alpine.DEB.2.10.1503261221470.5119@davide-lnx3>
On 03/26/2015 08:39 PM, Davide Libenzi wrote:
> On Thu, 26 Mar 2015, David Rientjes wrote:
>
>> Yes, this munmap() behavior of lengths <= hugepage_size - PAGE_SIZE for a
>> hugetlb vma is long standing and there may be applications that break as a
>> result of changing the behavior: a database that reserves all allocated
>> hugetlb memory with mmap() so that it always has exclusive access to those
>> hugepages, whether they are faulted or not, and maintains its own hugepage
>> pool (which is common), may test the return value of munmap() and depend
>> on it returning -EINVAL to determine if it is freeing memory that was
>> either dynamically allocated or mapped from the hugetlb reserved pool.
>
> You went a long way to create such a case.
> But, in your case, that application will erroneously considering hugepage
> mmaped memory, as dynamically allocated, since it will always get EINVAL,
> unless it passes an aligned size. Aligned size, which a fix like the one
> posted in the patch will still leave as success.
> OTOH, an application, which might be more common than the one you posted,
> which calls munmap() to release a pointer which it validly got from a
> previous mmap(), will leak huge pages as all the issued munmaps will fail.
>
>
>> If we were to go back in time and decide this when the munmap() behavior
>> for hugetlb vmas was originally introduced, that would be valid. The
>> problem is that it could lead to userspace breakage and that's a
>> non-starter.
>>
>> What we can do is improve the documentation and man-page to clearly
>> specify the long-standing behavior so that nobody encounters unexpected
>> results in the future.
>
> This way you will leave the mmap API with broken semantics.
> In any case, I am done arguing.
> I will leave to Andrew to sort it out, and to Michael Kerrisk to update
> the mmap man pages with the new funny behaviour.
+ CC's
You know that people don't always magically CC themselves, or read all of
lkml/linux-mm? :)
>
>
> - 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>
>
--
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>
prev parent reply other threads:[~2015-03-27 9:45 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
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 [this message]
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=551526C8.1000105@suse.cz \
--to=vbabka@suse.cz \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=davidel@xmailserver.org \
--cc=emunson@akamai.com \
--cc=hughd@google.com \
--cc=joern@logfs.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mtk.manpages@gmail.com \
--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