Kernel Linux recebe correção de bug de longa data que tornava o “tracing” inseguro

Escrito por
Emanuel Negromonte
Emanuel Negromonte é Jornalista, Mestre em Tecnologia da Informação e atualmente cursa a segunda graduação em Engenharia de Software. Com 14 anos de experiência escrevendo sobre...

Mais segurança e previsibilidade para quem depende do tracing no Linux.

Uma falha sutil, mas potencialmente perigosa, na interface trace_marker do Kernel Linux foi finalmente corrigida. A mudança resolve um problema antigo que poderia causar “page faults” (falhas de página) em momentos críticos, quando as interrupções estavam desabilitadas. Essa correção torna mais seguro para as ferramentas de userspace escreverem rapidamente no buffer de tracing do kernel, uma funcionalidade essencial para depuração de performance em tempo real. A solução foi adotar uma função mais moderna, copy_from_user_nofault(), que lida com as falhas de página de forma segura.

Correção crucial para o trace_marker

yW1qqfdb image
Kernel Linux recebe correção de bug de longa data que tornava o “tracing” inseguro 3

Se você já “anotou” eventos no tracing escrevendo em /sys/kernel/tracing/trace_marker, sabe o quão útil é marcar, a partir do userspace, trechos relevantes de execução. O problema é que, desde uma alteração de 2016, esse caminho usava __copy_from_user_inatomic() sem desabilitar corretamente as falhas de página — o que, em seções críticas (por exemplo, com preempção desativada), poderia disparar um fault, agendar indevidamente e até migrar a tarefa de CPU, bagunçando a telemetria. O patch substitui essa chamada por copy_from_user_nofault(), que já faz o bloqueio necessário e evita o fault. Resultado: menos risco, mais previsibilidade para quem depende de Linux kernel tracing em produção.

Outras melhorias de estabilidade no ftrace

O “polimento” não parou no trace_marker. O mantenedor Steven Rostedt enviou um pacote de fixes que reforçam a confiabilidade de ftrace e amigos — exatamente o tipo de cuidado que não vira manchete, mas salva o seu pós-mortem.

  • fgraph: correção no caminho de erro para gerenciar o power-management notifier. Em certos cenários, uma falha durante o registro do tracer podia deixar um notifier registrado incorretamente, gerando warnings na próxima tentativa. O ajuste garante que o unregister só ocorra no contexto certo (ou seja, evita “desmontar” algo que não foi montado), eliminando ruídos e potenciais inconsistências.
  • osnoise: conserto para um crash quando uma CPU mask de tamanho zero era passada por engano. Nessa condição, kmalloc() retorna ZERO_SIZE_PTR e, se não for checado, vira null-ptr-deref. Agora, ao receber tamanho 0, a escrita simplesmente retorna 0 — comportamento explícito, sem queda do sistema. É o tipo de guard-rail que você torce para nunca acionar… até o dia em que ele te salva.
  • trace_pid_write: eliminação de um warning intermitente ao processar listas de PIDs quando faltava memória (cenário inclusive testado com fault injection). A rotina passa a checar o retorno de trace_pid_list_set() e aborta cedo em caso de erro — nada de seguir em frente com estado parcial.

No agregado, essas mudanças deixam o ecossistema de tracing do Linux mais previsível: menos falhas de borda, menos warnings enganosos, e mais confiança para perfis de produção e pipelines de observabilidade que escrevem eventos de alta frequência no ring buffer. Em vez de uma “grande feature”, é um daqueles ciclos de manutenção que fazem toda a diferença quando você precisa responder, às 3 da manhã, à pergunta: “o que diabos aconteceu com o meu sistema?” — e quer confiar nas pistas que o tracing te dá.

Compartilhe este artigo