https://bugzilla.novell.com/show_bug.cgi?id=858959
https://bugzilla.novell.com/show_bug.cgi?id=858959#c1
Michal Hocko changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mhocko@suse.com
--- Comment #1 from Michal Hocko 2014-01-16 09:53:48 CET ---
OK, so it seems that the testcase tries to do mmap(NULL, 0x1000, prot,
MAP_HUGETLB, -1, 0) or something like that. It assumes that the length has to
be aligned to the units of pages which back the mapping.
This assumption is too strict and in fact doesn't comply with POSIX
http://pubs.opengroup.org/onlinepubs/7908799/xsh/mmap.html
"
Thus, while the argument len need not meet a size or alignment constraint, the
implementation will include, in any mapping operation, any partial page
specified by the range [pa, pa + len).
"
And the kernel code does exactly this for both regular pages and hugetlb pages
as well.
Therefore the objective for the test case which is:
/*
* Test rationale:
*
* Just as normal mmap()s can't have an address, length or offset
* which is not page aligned, so hugepage mmap()s can't have an
* address, length or offset with is not hugepage aligned.
*
* However, from time to time when the various mmap() /
* get_unmapped_area() paths are updated, somebody misses one of the
* necessary checks for the hugepage paths. This testcase ensures
* that attempted hugepage mappings with parameters which are not
* correctly hugepage aligned are rejected.
*/
doesn't hold for the length part (other 2 are valid).
What might be relevant and interesting to test though is whether the partial
pages are handled correctly. Something like mmap hugepagesize + few bytes and
then access 2*hugepagesize long area.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.