Quando um processo é executado, observando o código do kernel para environ_read(), parece que se o mm_struct ainda não existe / é nulo ou o membro env_end desse mm_struct é nulo, environ_read() retornará 0 ~imediatamente.
Minha pergunta é: existem proteções WRT fork/exec races de modo que (pseudocódigo à frente)
if ((pid = fork) != 0)
execv*("/bin/exe", {"exe", "-l"}, &envp)
read("/proc/${pid}/environ")
Não pode:
R: ler erroneamente um env de comprimento zero devido a disputas com execve e a leitura subsequente (por exemplo: assumir que o programa de espaço do usuário que emite a leitura é multithread ou executa E/S assíncrona)
B: ler erroneamente um env parcial (assumindo que o código do espaço do usuário não está causando uma leitura curta devido a um bug no código do espaço do usuário)
C: leia erroneamente o ambiente dos pais
As leituras de /p/p/environ são atômicas?
Acabei corrigindo o código do kernel só para ter certeza e a resposta é definitivamente NÃO. Não é seguro assumir que se o pid existe / fork retornou > 0, você pode assumir que o final é seguro e acessível em /p/p/environ.
Você pode obter uma leitura de comprimento zero errônea se você usar fork(), exec() e então tentar ler /proc/pid/environ para o novo processo.
Por que não bloquear na leitura até que esteja pronto Linux upstream? Ah, bem, pergunta respondida!
envirion_read faz isso:
Isso significa que se você ler muito cedo, a leitura receberá zero bytes, então eles colocaram o ônus no espaço do usuário para verificar a leitura.