On Sun, 29 Mar 2015, Hugh Dickins wrote:

On Thu, 26 Mar 2015, David Rientjes wrote:

quoted

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

I don't want to work out the list myself: is_vm_hugetlb_page() is
special-cased all over, and different syscalls react differently.

Which is another reason why, like you, I much prefer not to interfere
with the long established behavior: it would be very easy to introduce
bugs and worse inconsistencies.

And mprotect(2) is a good example of why we should not mess around
with the long established API here: changing an mprotect from failing
on a particular size to acting on a larger size is not a safe change.

Eric, I apologize for bringing you in to the discussion, and then
ignoring your input.  I understand that you would like MAP_HUGETLB
to behave more understandably.  We can all agree that the existing
behavior is unsatisfying.  But it's many years too late now to 
change it around - and I suspect that a full exercise to do so would
actually discover some good reasons why the original choices were made.

No worries, my main concern was avoiding the confusion that led me down
the rabbit hole of compaction and mlock.  As long as the documentation,
man pages, and the code all agree I am satisfied.  I would have
preferred to make the code match the docs, but I understand that
changing the code now introduces a risk of breaking userspace.

It is charitable of you to assume that there were good reasons for the
original decision.  But as the author of the code in question, I suspect
the omission was one of my own inexperience.

Eric