alignment and granularity of mmap

I am confused by the specificati开发者_如何学JAVAon of mmap.

Let pa be the return address of mmap (the same as the specification)

pa = mmap(addr, len, prot, flags, fildes, off);

In my opinion after the function call succeed the following range is valid

[ pa, pa+len )

My question is whether the range of the following is still valid?

[ round_down(pa, pagesize) , round_up(pa+len, pagesize) )

[ base, base + size ] for short

That is to say:

1. is the base always aligned on the page boundary?
2. is the size always a multiple of pagesize (the granularity is pagesize in other words)?

Thanks for your help.

I think it is implied in this paragraph :

The off argument is constrained to be aligned and sized according to the value returned by sysconf() when passed _SC_PAGESIZE or _SC_PAGE_SIZE. When MAP_FIXED is specified, the application shall ensure that the argument addr also meets these constraints. The implementation performs mapping operations over whole pages. Thus, while the argument len need not meet a size or alignment constraint, the implementation shall include, in any mapping operation, any partial page specified by the range [pa,pa+len).

But I'm not sure and I do not have much experience on POSIX.

• Please show me some more explicit and more definitive evidence
• Or show me at least one system which supports POSIX and has different behavior

Thanks agian.

---

Your question is fairly open-ended, considering that mmap has many different modes and configurations, but I'll try to cover the most important points.

Take the case in which you are mapping a file into memory. The beginning of the data in the file will always be rooted at the return address of mmap(). While the operating system may have actually created maps at page boundaries, I do not believe the POSIX standard requires the OS to make this memory writable (for example it could force segfaults on these regions if it wanted to). In the case of mapping files it doesn't make sense for this additional memory address regions to be backed by a file, it makes more sense for these regions to be undefined.

For MMAP_ANONYMOUS, however, the memory is likely writable--but, again, it would be unwise to use this memory.

Additionally, when you are using mmap() you are actually using glibc's version of mmap(), and it may slice and dice memory anyway it sees fit. Finally, it is worth noting that on OSX, which is POSIX compliant, none of the quoted text you presented appears in the man page for mmap().