Querrías la bandera MAP_ANONYMOUS para mmap. Y el MAP_GROWSDOWN ya que quieres usarlo como una pila.
Algo como:
void *stack = mmap(NULL,initial_stacksize,PROT_WRITE|PROT_READ,MAP_PRIVATE|MAP_GROWSDOWN|MAP_ANONYMOUS,-1,0);
Consulte la página de manual de mmap para obtener más información. Y recuerda, clonar es un concepto de bajo nivel, que no debes usar a menos que realmente necesites lo que ofrece. Y ofrece mucho control, como configurar su propia pila, en caso de que quiera hacer algún truco (como tener la pila accesible en todos los procesos relacionados). A menos que tenga una muy buena razón para usar clon, quédese con fork o pthreads.
Las pilas no son, y nunca podrán ser, ilimitadas en su espacio de crecimiento. Como todo lo demás, viven en el espacio de direcciones virtuales del proceso y la cantidad en la que pueden crecer siempre está limitada por la distancia a la región de memoria asignada adyacente.
Cuando las personas hablan sobre el crecimiento dinámico de la pila, lo que podrían querer decir es una de dos cosas:
- Las páginas de la pila pueden ser páginas cero de copia en escritura, que no obtienen copias privadas hasta que se realiza la primera escritura.
- Es posible que las partes inferiores de la región de la pila aún no estén reservadas (y, por lo tanto, no cuenten para el cargo de compromiso del proceso, es decir, la cantidad de memoria física/intercambio que el kernel ha contabilizado como reservada para el proceso) hasta que se alcance una página de protección , en cuyo caso el kernel confirma más y mueve la página de protección, o elimina el proceso si no queda memoria para confirmar.
Tratando de confiar en el MAP_GROWSDOWN la bandera es poco fiable y peligrosa porque no puede protegerte contra mmap creando una nueva asignación justo al lado de su pila, que luego será golpeada. (Consulte http://lwn.net/Articles/294001/) Para el subproceso principal, el kernel reserva automáticamente el tamaño de pila ulimit valor del espacio de direcciones (no memoria ) debajo de la pila y evita mmap de asignarlo. (Pero ¡cuidado! ¡Algunos kernels dañados con parches de proveedores deshabilitan este comportamiento, lo que provoca daños aleatorios en la memoria!) Para otros subprocesos, simplemente debe mmap el rango completo de espacio de direcciones que el subproceso podría necesitar para la pila al crearlo. No hay otra manera. podrías haga que la mayor parte no se pueda escribir/leer inicialmente, y cámbielo en caso de fallas, pero luego necesitaría controladores de señal y esta solución no es aceptable en una implementación de subprocesos POSIX porque interferiría con los controladores de señal de la aplicación. (Tenga en cuenta que, como extensión, el núcleo podría oferta especial MAP_ banderas para entregar una señal diferente en lugar de SIGSEGV en el acceso ilegal al mapeo, y luego la implementación de subprocesos podría capturar y actuar sobre esta señal. Pero Linux en la actualidad no tiene esa función.)
Finalmente, ten en cuenta que el clone syscall no toma un argumento de puntero de pila porque no lo necesita. La llamada al sistema se debe realizar desde el código ensamblador, ya que se requiere que el contenedor del espacio de usuario cambie el puntero de la pila en el subproceso "secundario" para que apunte a la pila deseada y evite escribir algo en la pila principal.
En realidad, clone toma un argumento de puntero de pila, porque no es seguro esperar para cambiar el puntero de pila en el "hijo" después de regresar al espacio de usuario. A menos que todas las señales estén bloqueadas, un controlador de señales podría ejecutarse inmediatamente en la pila incorrecta y, en algunas arquitecturas, el puntero de la pila debe ser válido y apuntar a un área segura para escribir en todo momento.
No solo es imposible modificar el puntero de la pila desde C, sino que tampoco podría evitar la posibilidad de que el compilador golpee la pila principal después de la llamada al sistema pero antes de que se cambie el puntero de la pila.