alineación y granularidad de mmap

Question

Estoy confundido por el specification of mmap.

Vamos pa ser la dirección de retorno de mmap (la misma que la especificación)

pa = mmap (addr, len, Prot, banderas, fildes, off);

En mi opinión después de la llamada a la función éxito del siguiente rango es válida

[pa, pa + len)

Mi pregunta es si el rango de los siguientes es ¿todavía válido?

[ROUND_DOWN (pa, tamaño de página), round_up (PA + len, tamaño de página))
[base, base + size] por sus siglas en

Es decir:

1. es el base siempre alineado en el límite de la página?
2. es el size siempre un múltiplo de pagesize (la granularidad es pagesize en otras palabras)?

Gracias por su ayuda.

creo que se da a entender en este párrafo:

El fuera argumento está obligado a estar alineados y dimensionados de acuerdo con el valor devuelto por sysconf() cuando se pasa _SC_PAGESIZE o _SC_PAGE_SIZE. Cuando se especifica MAP_FIXED, la aplicación debe garantizar que el argumento addr también cumple estas restricciones. La implementación realiza operaciones de mapeo en páginas completas. Por lo tanto, aunque el argumento len no necesita cumplir con una restricción de tamaño o alineación, la implementación incluirá, en cualquier operación de mapeo, cualquier página parcial especificada por el rango [pa, pa + len).

Pero no estoy seguro y no tengo mucha experiencia en POSIX.

• Por favor, dame algo más explícita y más definitiva pruebas
• o Me muestran al menos un sistema que soporta POSIX y tiene un comportamiento diferente

Gracias alquilásemos.

Answer 1

Su pregunta es bastante abierta, teniendo en cuenta que mmap tiene muchos modos y configuraciones diferentes, pero trataré de cubrir los puntos más importantes.

Tome el caso en el que está mapeando un archivo en la memoria. El comienzo de los datos en el archivo siempre estará enraizado en la dirección de retorno de mmap(). Si bien el sistema operativo puede haber creado mapas en los límites de la página, no creo que el estándar POSIX requiera que el sistema operativo haga que esta memoria pueda escribirse (por ejemplo, podría forzar segfaults en estas regiones si así lo deseara). En el caso de los archivos de asignación, no tiene sentido que estas regiones de direcciones de memoria adicionales sean respaldadas por un archivo, tiene más sentido que estas regiones no estén definidas.

Para MMAP_ANONYMOUS, sin embargo, es probable que la memoria se pueda escribir, pero, de nuevo, no sería prudente usar esta memoria.

Además, cuando está utilizando mmap() en realidad está usando la versión de mmap() de glibc, y puede cortar y cortar la memoria de cualquier manera que le parezca. Finalmente, vale la pena señalar que en OSX, que es compatible con POSIX, ninguno de los textos citados que usted presenta aparece en la página de manual de mmap().