Como a alocação de pilha funciona no Linux?

O sistema operacional reserva a quantidade fixa de espaço virtual válido para a pilha ou outra coisa? Posso produzir um estouro de pilha apenas usando grandes variáveis ​​locais?

Eu escrevi um pequeno Cprograma para testar minha suposição. Está sendo executado no X86-64 CentOS 6.5.

#include <string.h>
#include <stdio.h>
int main()
{
    int n = 10240 * 1024;
    char a[n];
    memset(a, 'x', n);
    printf("%x\n%x\n", &a[0], &a[n-1]);
    getchar();
    return 0;
}

A execução do programa fornece &a[0] = f0ceabe0e&a[n-1] = f16eabdf

Os mapas proc mostram a pilha: 7ffff0cea000-7ffff16ec000. (10248 * 1024B)

Então eu tentei aumentar n = 11240 * 1024

A execução do programa fornece &a[0] = b6b36690e&a[n-1] = b763068f

Os mapas proc mostram a pilha: 7fffb6b35000-7fffb7633000. (11256 * 1024B)

ulimit -simprime 10240no meu PC.

Como você pode ver, em ambos os casos, o tamanho da pilha é maior do que o indicado ulimit -s. E a pilha cresce com maior variável local. O topo da pilha está de alguma forma 3-5kB a mais &a[0](AFAIK, a zona vermelha é 128B).

Então, como esse mapa de pilha é alocado?

Parece que o limite de memória da pilha não está alocado (de qualquer forma, não poderia com pilha ilimitada). https://www.kernel.org/doc/Documentation/vm/overcommit-accounting diz:

O crescimento da pilha da linguagem C cria um mremap implícito. Se você quer garantias absolutas e corre perto do limite, DEVE mapear sua pilha para o maior tamanho que achar necessário. Para o uso típico da pilha, isso não importa muito, mas é uma caixa de canto se você realmente se importa

No entanto, o mapeamento da pilha seria o objetivo de um compilador (se houver uma opção para isso).

EDIT: Após alguns testes em uma máquina Debian x84_64, eu descobri que a pilha cresce sem nenhuma chamada do sistema (de acordo com strace). Então, isso significa que o kernel cresce automaticamente (é o que o "implícito" significa acima), ou seja, sem explícito mmap/ mremapdo processo.

Foi muito difícil encontrar informações detalhadas confirmando isso. Eu recomendo Noções básicas sobre o Linux Virtual Memory Manager, de Mel Gorman. Suponho que a resposta esteja na Seção 4.6.1 Manipulando uma falha de página , com a exceção "Região inválida, mas está ao lado de uma região expansível como a pilha" e a ação correspondente "Expandir a região e alocar uma página". Veja também D.5.2 Expandindo a pilha .

Outras referências sobre o gerenciamento de memória do Linux (mas com quase nada sobre a pilha):

• Memória FAQ
• O que todo programador deve saber sobre memória de Ulrich Drepper

EDIT 2: Esta implementação tem uma desvantagem: em casos de canto, uma colisão de pilha não pode ser detectada, mesmo no caso em que a pilha seja maior que o limite! O motivo é que uma gravação em uma variável na pilha pode acabar na memória heap alocada; nesse caso, não há falha de página e o kernel não pode saber que a pilha precisava ser estendida. Veja meu exemplo na discussão Colisão silenciosa de pilha e pilha no GNU / Linux que iniciei na lista de ajuda do gcc. Para evitar isso, o compilador precisa adicionar algum código na chamada de função; isso pode ser feito com o -fstack-checkGCC (consulte a resposta de Ian Lance Taylor e a página de manual do GCC para obter detalhes).

Kernel Linux 4.2

• mm / mmap.c # acct_stack_growth decide se irá falhar ou não. Usa o rlim[RLIMIT_STACK]que corresponde ao POSIXgerlimit(RLIMIT_STACK)
• arch / x86 / mm / fault.c # do_page_fault é o manipulador de interrupções que inicia uma cadeia que acaba chamandoacct_stack_growth
• arch / x86 / entry / entry_64.S configura o manipulador de falhas da página. Você precisa saber um pouco sobre paginação para entender essa parte: Como funciona a paginação x86? | Estouro de pilha

Programa de teste mínimo

Em seguida, podemos testá-lo com um programa NASM mínimo de 64 bits:

global _start
_start:
    sub rsp, 0x7FF000
    mov [rsp], rax
    mov rax, 60
    mov rdi, 0
    syscall

Certifique-se de desativar o ASLR e remover as variáveis ​​de ambiente, pois elas vão para a pilha e ocupam espaço:

echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
env -i ./main.out

O limite está um pouco abaixo do meu ulimit -s(8MiB para mim). Parece que isso se deve a dados adicionais especificados no System V, inicialmente colocados na pilha, além do ambiente: Parâmetros da linha de comando do Linux 64 no Assembly | Estouro de pilha

Se você é sério sobre isso, o TODO cria uma imagem mínima do initrd que começa a gravar a partir do topo da pilha e diminui e, em seguida, execute-a com QEMU + GDB . Coloque um dprintfno loop imprimindo o endereço da pilha e um ponto de interrupção em acct_stack_growth. Será glorioso.

Relacionado:

• /software/207386/how-are-the-size-of-the-stack-and-heap-limited-by-the-os
• De onde é alocada a memória da pilha para um processo Linux? | Estouro de pilha
• O que é a pilha do Linux? | Estouro de pilha
• Qual é a profundidade máxima de recursão no Python e como aumentá-la? no estouro de pilha

Por padrão, o tamanho máximo da pilha é configurado para 8 MB por processo,
mas pode ser alterado usando ulimit:

Mostrando o padrão em kB:

$ ulimit -s
8192

Defina como ilimitado:

ulimit -s unlimited

afetando o shell e subshells atuais e seus processos filhos.
( ulimité um comando interno do shell)

Você pode mostrar o intervalo de endereços da pilha real em uso com:
cat /proc/$PID/maps | grep -F '[stack]'
no Linux.