Em um movimento que destaca os desafios no desenvolvimento de tecnologias de ponta, o kernel Linux está desabilitando temporariamente a funcionalidade de bpf_timer em compilações com PREEMPT_RT (tempo real). A decisão, embora drástica, é uma medida pragmática para garantir a estabilidade de sistemas que dependem de latências ultrabaixas e previsíveis. A mudança veio no pacote de “bpf-fixes” que Linus Torvalds puxou para a árvore principal — com o próprio resumo deixando claro: “Disallow bpf_timer in PREEMPT_RT for now; a proper solution está sendo discutida para o bpf-next”.
Quando tecnologias de ponta colidem
Pense no PREEMPT_RT como um “modo concentração total” do kernel — ele remodela subsistemas inteiros para que cada interrupção, cada bloqueio, cada preempção seja previsível. É assim que o Linux se torna apto a operar em robôs industriais, áudio profissional e ambientes onde cada microssegundo conta. Já o BPF é a “máquina virtual do kernel”: um mecanismo seguro para executar código sob medida (observabilidade, rede, segurança) dentro do kernel, sem precisar recompilar o sistema. O bpf_timer é um recurso desse ecossistema: permite que programas BPF agendem callbacks temporizados.
O problema? Esses timers, do jeito que estavam, podem “esbarrar” nas garantias rígidas de tempo do PREEMPT_RT. Em testes, ao rodar os selftests de timer, surgiam avisos do tipo “sleeping function called from invalid context” — um cheiro clássico de caminho de bloqueio incompatível com RT. A correção de curto prazo foi simples e clara: o verificador do BPF agora rejeita o uso de bpf_timer quando o PREEMPT_RT está habilitado, retornando -EOPNOTSUPP, e os próprios selftests foram ajustados para pular esses casos sob RT.
Se você trabalha com redes de baixa latência, telemetria no kernel ou pipelines de observabilidade que usam BPF em sistemas RT, o recado é direto: não conte com bpf_timer em RT por enquanto. A boa notícia é que nada foi “queimado” — a comunidade não está abandonando a ideia de timers em BPF para RT; apenas apertou o freio de mão para não comprometer a estabilidade de quem precisa de determinismo absoluto. O próprio pull traz isso preto no branco: o tema volta na próxima janela de desenvolvimento (bpf-next).
O caminho a seguir: em busca de uma solução definitiva
O processo ilustra como a “engenharia de compromisso” funciona no mundo do kernel Linux. De um lado, a promessa de flexibilidade e inovação do BPF; do outro, as garantias duríssimas do PREEMPT_RT. Quando as duas forças entram em tensão, a prioridade — ao menos neste ciclo — foi preservar a estabilidade do tempo real. Enquanto isso, patches de acompanhamento ajustam a infraestrutura (inclusive auto-testes) para refletir o novo comportamento, evitando falsos negativos e ruído em pipelines de CI.
E o que esperar? A solução “certa” provavelmente envolverá repensar como esses timers interagem com contextos onde bloqueios e preempções têm regras especiais — talvez exigindo caminhos “RT-safe” explícitos, novas primitivas ou restrições mais finas impostas pelo verificador. O importante é que o fluxo upstream foi transparente: o pull request de Alexei Starovoitov para Linus Torvalds chamou o problema, creditou o trabalho de Leon Hwang e sinalizou o plano: pausa agora, engenharia cuidadosa depois. Para quem acompanha de perto, é mais um episódio do “como” o Linux mantém seu equilíbrio entre inovação acelerada e confiabilidade férrea.
Links úteis:
• Pull “bpf-fixes” com a nota “Disallow bpf_timer in PREEMPT_RT for now” — commit de merge.
• Patch específico: “bpf: Reject bpf_timer for PREEMPT_RT” (Leon Hwang), com detalhes do aviso em RT e retorno -EOPNOTSUPP — entrada de commit (seção “bpf: Reject bpf_timer for PREEMPT_RT”).
