Algumas possíveis condições de corrida com sinais e PIDs

Digamos que estou no meio de uma chamada para kill(2) para um processo zumbi (ou seja, já estou no espaço do kernel e executando o código do kernel para iniciar o sinal). Ao mesmo tempo, o pai do zumbi chama wait(2). É possível que minha chamada para kill(2) acabe tentando agir em um processo diferente?

Sim. Pode haver um período de tempo arbitrário entre um processo que emite a killchamada do sistema e o ponto em que o kernel decide qual processo encerrar. Parte desse tempo é gasto no processo de preparação da chamada do sistema e parte desse tempo é gasto no kernel. A qualquer momento desse processamento, o kernel pode decidir mudar para a execução de algum outro thread (seja devido a uma interrupção ou porque o kernel tentou obter um bloqueio que já estava em uso). O processo em execução kille o processo em execução waitpodem ter as chamadas do sistema atendidas por processadores diferentes, portanto, eles podem até estar no modo kernel ao mesmo tempo.

A killchamada do sistema não tem muito o que fazer, portanto, uma interrupção não é muito provável. Mas isso pode acontecer, e acontecerá se você tentar várias vezes. E em um sistema multiprocessador, uma corrida é mais provável.

Você pode ver como o kernel do Linux lida com uma chamada de sistema observando o código-fonte. Elixir fornece um visualizador online conveniente com referências cruzadas. A implementação do killsinal começa com SYSCALL_DEFINE2(kill, …)(o 2 é porque existem dois parâmetros). Como você pode ver, o código consiste em uma função muito curta prepare_kill_siginfoe depois no início da função kill_something_infoaté o ponto em que essa função chama read_lock(&tasklist_lock). Uma vez que a chamada retorna, nenhuma entrada pode ser adicionada ou removida da tabela de processos e, em particular, a entrada para pidcontinua designando o mesmo processo, até que a chamada correspondente seja read_unlockimediatamente antes do retorno da função. Isso deixa apenas um tempo muito curto para que ocorram interrupções ou para outros processadores adquirirem o bloqueio da lista de tarefas primeiro, mas esse tempo não é e não pode ser zero.

Alguns kernels, como o OpenBSD, evitam que um PID seja reutilizado logo após a destruição do objeto do processo. Isso torna a condição de corrida menos provável, possivelmente até impossível se o sistema estiver levemente carregado (se for apenas você no seu PC fazendo nada além de tentar executar dois processos). Mas a condição de corrida permanece possível se o sistema estiver suficientemente carregado (com muitos processos sendo criados e eliminados). Não há como impedir a corrida.

Devido ao potencial para uma corrida, o projeto de um software multiprocesso geralmente deve providenciar que os processos sejam gerenciados por seus pais, ou pelo menos pelo líder do grupo. O pai pode garantir que nunca tente encerrar um processo que já esteja aguardando.

Digamos que eu matei(2)-ed (isto é, retornei com sucesso ao espaço do usuário após a chamada) um processo, mas antes que meu sinal possa ser entregue, um sinal diferente é capturado e mata o processo. Nesse caso, presumo que é garantido que meu sinal será destruído.

Sim, uma vez que seu processo retornou da killchamada do sistema, o kernel decidiu qual processo (ou processo zumbi) o sinal tem como alvo. É possível que o sinal ainda não tenha sido processado e nunca seja entregue se o alvo já for um zumbi. Mas o kernel escolhe para qual entrada da tabela de processos o sinal se destina durante a execução da chamada do sistema.