[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.10.1504021536210.15536@chino.kir.corp.google.com>
Date: Thu, 2 Apr 2015 15:40:56 -0700 (PDT)
From: David Rientjes <rientjes@...gle.com>
To: Hugh Dickins <hughd@...gle.com>
cc: Andrew Morton <akpm@...ux-foundation.org>,
Jonathan Corbet <corbet@....net>,
Davide Libenzi <davidel@...ilserver.org>,
Luiz Capitulino <lcapitulino@...hat.com>,
Shuah Khan <shuahkh@....samsung.com>,
Andrea Arcangeli <aarcange@...hat.com>,
Joern Engel <joern@...fs.org>,
Jianguo Wu <wujianguo@...wei.com>,
Eric B Munson <emunson@...mai.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
linux-doc@...r.kernel.org
Subject: Re: [patch 1/2] mm, doc: cleanup and clarify munmap behavior for
hugetlb memory
On Sun, 29 Mar 2015, Hugh Dickins wrote:
> > munmap(2) of hugetlb memory requires a length that is hugepage aligned,
> > otherwise it may fail. Add this to the documentation.
>
> Thanks for taking this on, David. But although munmap(2) is the one
> Davide called out, it goes beyond that, doesn't it? To mprotect and
> madvise and ...
>
Yes, good point, munmap(2) isn't special in this case, the alignment to
the native page size of the platform should apply to madvise, mbind,
mincore, mlock, mprotect, remap_file_pages, etc.
I'd hesitate to compile any authoritative list on the behavior in
Documentation/vm/hugetlbpage.txt since it would exclude future extensions,
but I'll update it to be more inclusive of other mm syscalls rather than
specify only munmap(2).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists