Por que irqs_disabled () é uma maneira insegura de desativar a preempção?

Question

Bloqueio adequado de acordo com um kernel preemptiva: mantendo o Kernel Code Preempt-Safe artigo diz,

But keep in mind that 'irqs disabled' is a fundamentally unsafe way of disabling preemption - any spin_unlock() decreasing the preemption count to 0 might trigger a reschedule. A simple printk() might trigger a reschedule.

Se os IRQs estiverem desabilitados, a interrupção do timer também deve ser desativada no núcleo da CPU. Naturalmente, deve desativar o agendador (preempção) por sua vez. Por que está chamando irqs disabled () uma maneira insegura de desativar a preempção?

Além disso, como o printk () pode desencadear um reescalonamento?

    

Answer 1

Sim, se os IRQs estiverem desabilitados, a interrupção do timer será desativada e o agendamento de tarefas não ocorrerá mais. A parte insegura é o "se": se você está confiando em IRQs desabilitados, precisa ter absoluta certeza de que todo o código executado com IRQs desabilitados respeita isso. Isso pode ser bastante difícil no kernel desde os spinlocks desabilitam e habilitam a preempção (junto com os IRQs em alguns casos), e muitos trechos de código usam bloqueios, incluindo printk (para garantir que as mensagens de log não sejam confundidas). Sempre que um bloqueio é liberado, você corre o risco de reagendar (para executar o código que estava aguardando no bloqueio), mesmo se os IRQs estiverem desabilitados: preempt_enable() chama explicitamente __preempt_schedule() quando seu contador chegar a zero, então nenhuma interrupção do temporizador é necessária.

Assim, é mais seguro usar as funções de suporte de preempção adequadas, especialmente em termos de proteção do futuro: você pode estar bem ciente das restrições no código que está escrevendo agora, mas outra pessoa que alterá-lo não ( e "outra pessoa" inclui "você daqui a seis meses").