Detetar e analisar fugas de memória do kernel com o kmemleak

O que o kmemleak deteta no kernel

Kmemleak apoia a depuração do kernel do Linux, procurando objetos de memória que possam estar órfãos. Para tal, rastreia as alocações suportadas e verifica se é possível identificar referências a esses objetos nas áreas de memória analisadas. Um objeto que não seja reconhecido como acessível surge como uma possível fuga de memória, não como um erro definitivamente comprovado.

Imagina que um módulo do kernel reserve um objeto e, em seguida, perca a última referência a esse objeto, sem libertar a memória. Se o kmemleak, durante a sua Pesquisa de referências Se já não houver nenhuma referência ao objeto, pode denunciá-lo como suspeito. A denúncia fornece um ponto de partida para analisar a alocação e o ciclo de vida previsto no código.

O processo assemelha-se à pesquisa de acessibilidade de um recolhedor de lixo, mas não assume a sua função de limpeza: o Kmemleak não liberta os objetos reportados nem repara o código. Para determinar se um objeto está efetivamente perdido, é necessário analisar a sua utilização, as relações de propriedade e a libertação prevista.

Uma fuga no kernel diz respeito à memória gerida pelo código do kernel ou por um módulo. Uma fuga num serviço PHP ou noutro processo do espaço do utilizador constitui uma classe diferente de erros; o kmemleak não analisa a pilha desses processos. Para uma abordagem mais abrangente Detecção de fugas de memória em serviços de alojamento Por isso, também se podem considerar dados de processo e outras ferramentas de diagnóstico.

O aumento da utilização da RAM, por si só, não prova que haja um Fuga de memória nem a sua localização. Também uma alteração no âmbito do trabalho ou a conservação de dados por períodos mais longos podem influenciar essa necessidade. Um ponto de partida sensato é, portanto, um processo que possa ser delimitado em termos temporais e funcionais, no qual seja possível investigar de forma específica uma suspeita relacionada com o kernel.

Por que razão as notificações continuam a ser casos suspeitos

A pesquisa de valores de ponteiro não consegue reconhecer todos os significados que um programa atribui a uma referência. Se uma referência válida se encontrar fora das áreas analisadas ou estiver armazenada de forma a que o kmemleak não a reconheça, um objeto que ainda seja necessário pode parecer abandonado. Esta é uma possível Falso alarme: A notificação, por si só, não comprova que a autorização não tenha sido concedida.

O contrário também é possível. Um valor numérico pode, por acaso, parecer um ponteiro para um objeto, embora o código não o utilize como referência. O Kmemleak pode, então, classificar o objeto como acessível e ignorar uma fuga real. Uma saída vazia não é, portanto, prova de que o código analisado esteja isento de erros.

A isto acrescenta-se a amplitude das alocações monitorizadas: alocações diretas de páginas e ioremap De acordo com a documentação do kernel, estes não são monitorizados. Quem suspeitar de um aumento de memória nestas áreas não pode concluir, com base num relatório kmemleak discreto, que a causa em questão não constitui motivo de preocupação. Para tal, é necessária uma investigação com uma abordagem diferente.

O Acessibilidade Trata-se, portanto, de uma heurística técnica e não de uma análise semântica completa do programa. Não permite determinar com fiabilidade se uma referência detetada é utilizada de forma adequada ou se uma referência não detetada está, de facto, em falta. Cada resultado detetado corresponde a uma tarefa de verificação; a ausência de resultados detetados limita apenas a conclusão da respetiva verificação.

Para a avaliação, vale a pena recriar a suspeita em condições controladas e, em seguida, analisar o caminho de código correspondente. Em particular, é necessário esclarecer quem é o proprietário do objeto e quando este deve ser libertado. Só esta análise poderá fornecer uma explicação plausível para o resultado.

Verificar o ambiente de teste e os pré-requisitos

A documentação versionada para o Linux 6.6 serve aqui como base técnica. No entanto, a disponibilidade efetiva do kmemleak no teu sistema depende da compilação do kernel utilizada e da sua configuração, e não apenas do número da versão. Por isso, verifica o kernel da distribuição que está efetivamente instalado e regista a compilação e a configuração para análise posterior.

Um pré-requisito é a opção do kernel compilada CONFIG_DEBUG_KMEMLEAK. Distinta disso está a Ativação em tempo de execução: O kernel está configurado com CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF configurado, o parâmetro de arranque kmemleak=on pode ser necessário. Planeie expressamente as alterações ao processo de arranque para a configuração de teste aprovada.

Para aceder à interface de diagnóstico, é também necessário debugfs estar disponível e devidamente integrada. A configuração do kernel, a ativação e o acesso ao sistema de ficheiros são diferentes pontos de verificação: a ausência de uma interface, por si só, ainda não revela qual deles é a causa. Para o acesso, podem ser necessários direitos privilegiados.

Sempre que possível, utilize uma máquina virtual isolada ou um sistema de teste dedicado e obtenha autorização prévia para as alterações. O Kmemleak implica um esforço adicional nas alocações e libertações; o impacto depende do ambiente e da carga. Sem medições adequadas, não é possível indicar uma perda de desempenho generalizada.

Além do kernel, documente também o módulo em análise, o fluxo de execução previsto e o momento da saída. Os relatórios de diagnóstico podem conter endereços internos e outras informações sensíveis. Guarde-os num local com acesso restrito e, antes de os partilhar, verifique quais os dados que são efetivamente necessários para a análise de erros.

Interface e comandos de diagnóstico

Começa no sistema de teste partilhado com acesso de leitura a /sys/kernel/debug/kmemleak. O ficheiro apresenta os casos suspeitos atualmente comunicados. O acesso pode exigir direitos privilegiados; uma saída vazia descreve apenas o estado de diagnóstico visível e não comprova que o kernel esteja isento de fugas de memória.

Execute o seguinte comando num shell com direitos de leitura suficientes. Este comando não altera o estado de diagnóstico e é também adequado para guardar um primeiro relatório antes de avançar para outras etapas.

cat /sys/kernel/debug/kmemleak

Se o ficheiro não existir, há três causas possíveis: o kernel pode ter sido compilado sem CONFIG_DEBUG_KMEMLEAK Compilado, o kmemleak não está ativado em tempo de execução ou o debugfs não está montado no local esperado. A ausência do ficheiro, por si só, não determina qual das situações se aplica. Por isso, verifica separadamente a configuração de compilação, a configuração de arranque e a montagem.

A tabela faz uma distinção deliberada entre «ler» e Acessos de escrita: Uma verificação e a limpeza da lista visível alteram o estado de diagnóstico. A montagem do debugfs, caso seja necessária, também altera o sistema. Execute esses passos apenas com autorização e os direitos necessários para o efeito; o redirecionamento dos comandos de escrita também requer direitos suficientes.

Identificar casos suspeitos de forma reproduzível

Em primeiro lugar, guarde a saída completa da interface, juntamente com a data e hora, a compilação do kernel e a configuração de teste. As mensagens já existentes fazem parte do Balanço inicial e não devem ser atribuídos ao teste seguinte sem comparação. Guarde a saída num local seguro, uma vez que pode conter endereços internos e outras informações de diagnóstico.

Num sistema de teste disponibilizado, podes, em seguida, remover da lista de suspeitas as mensagens atualmente visíveis utilizando o seguinte comando de shell. O shell necessita de direitos de escrita na interface. O comando não liberta blocos de memória nem resolve a causa; sem uma cópia de segurança prévia, podem perder-se informações importantes.

echo clear > /sys/kernel/debug/kmemleak

Em seguida, inicie um processo o mais restrito e documentado possível, como, por exemplo, a inicialização e a limpeza controlada de um módulo a ser analisado. Registe quais os passos que foram executados e quando foram concluídos. Desta forma, uma descoberta posterior poderá ser comparada de forma mais concreta com o procedimento, sem que a mera proximidade temporal, por si só, prove uma relação causal.

Após o término, inicie uma verificação num shell com as permissões adequadas e, em seguida, leia novamente a interface. Ambos os comandos pressupõem que o kmemleak esteja ativo e que a interface debugfs esteja disponível.

echo scan > /sys/kernel/debug/kmemleak
cat /sys/kernel/debug/kmemleak

Repete o processo de forma controlada e dá-lhe tempo suficiente. Uma análise não tem de fornecer imediatamente um resultado reproduzível. Para uma regressão, compara o mesmo teste antes e depois da alteração do código, mantendo, na medida do possível, a mesma configuração do kernel e a mesma carga; documenta as diferenças que subsistirem. Uma nova suspeita corrobora uma hipótese, mas não substitui a verificação do ciclo de vida do objeto.

Teste do módulo e análise dos resultados

Num teste de módulo, podes, por exemplo, executar um percurso de inicialização e, em seguida, percorrer o percurso de limpeza previsto. Se, em seguida, surgir uma nova entrada, anota primeiro o tamanho do objeto, a idade e o contexto do processo, bem como os passos de teste associados. Estas informações ajudam a atribuir os resultados; por si só, ainda não indicam se o objeto deveria, de facto, ter sido libertado.

O Traço da pilha de alocação conduz ao ponto em que a memória foi solicitada. A partir daí, podes acompanhar no código quem fica com o objeto e qual o caminho pelo qual este deve ser libertado. O rastreio não tem de incluir o ponto em que a libertação não ocorreu: a alocação e a limpeza não efetuada podem ocorrer em funções diferentes.

Tem também em conta o Ordem de alocação: A documentação descreve a saída nesta ordem. Um objeto abandonado anterior pode dar origem a outras mensagens. Por isso, verifica se várias entradas pertencem ao mesmo conjunto de objetos ou ao mesmo caminho de erro antes de as considerares como defeitos independentes.

Para um teste de funcionamento opcional, a documentação atual do kernel descreve o módulo kmemleak-test, que gera intencionalmente fugas de memória. Utilize-o exclusivamente num ambiente de teste isolado e verifique previamente se está disponível nesse kernel específico e se está devidamente configurado. A documentação atual, que está em constante evolução, não garante a sua disponibilidade para todos os kernels mais antigos ou específicos de determinadas distribuições.

Mesmo com este módulo de diagnóstico, não é garantida uma notificação imediata ou um resultado positivo na primeira verificação. Regista a hora do teste e a sequência de verificação e repete a análise de forma controlada. Se o resultado permanecer em branco inicialmente, verifica os pré-requisitos e o procedimento, em vez de concluir, apenas com base nisso, que o ambiente de diagnóstico está a funcionar ou está avariado.

Verificar a causa em vez de ocultar a notificação

Num caso suspeito, começa por analisar o ciclo de vida do objeto reportado: que função reserva, quem assume a responsabilidade a seguir e quando deve ser libertado? O rastreio da pilha de alocação leva-te até à origem da reserva. Só é possível avaliar, com base no percurso do código, se existe um erro nesse ponto ou num ponto posterior.

Verifica, em especial, o Estrutura acionista nas transferências entre funções e módulos. Quando uma referência é passada, deve ficar claro qual das partes a mantém e qual das partes efetua a libertação. Compare também o percurso de limpeza normal com os percursos de interrupção e de erro, por exemplo, quando uma inicialização é concluída apenas parcialmente.

Pode ocorrer um erro mesmo que exista uma referência válida que o kmemleak não reconheça. Por isso, antes de o ignorar, verifica onde e de que forma o ponteiro é armazenado. Documenta a razão pela qual o objeto permanece acessível durante o seu ciclo de vida previsto e de que forma é, por fim, libertado.

Para casos especiais que tenham sido verificados, os programadores têm à disposição Anotações disponível: kmemleak_not_leak marca um objeto conhecido como não sendo uma fuga de memória, mas continua a analisar as suas referências. kmemleak_ignore exclui o objeto tanto do relatório como da análise. Consequentemente, as referências nele contidas podem não constar na análise.

Verifica a disponibilidade e a semântica da API no kernel efetivamente utilizado; a documentação atual da API não constitui automaticamente uma garantia para todas as compilações anteriores. Uma anotação não corrige nem a falta de uma autorização nem uma mudança de propriedade incorreta. Por isso, não a utilize apenas para fazer desaparecer uma saída indesejada.

Detecção de avarias e funcionamento seguro

Falta o ficheiro /sys/kernel/debug/kmemleak, verifica primeiro a compilação do kernel que foi efetivamente iniciada e a respetiva configuração. CONFIG_DEBUG_KMEMLEAK tem de estar presente; o número de versão de uma distribuição, por si só, não é suficiente para esse efeito. Regista a compilação e a configuração, para que as comparações posteriores sejam feitas com base nos mesmos dados.

Verifica, separadamente, o Ativação em tempo de execução e a integração do debugfs. No caso de CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF o parâmetro de arranque pode kmemleak=on pode ser necessário. Um ficheiro em falta não distingue, por si só, estas possíveis causas; as alterações ao processo de arranque ou a montagem do debugfs devem ser realizadas numa configuração de teste autorizada.

Se o resultado ficar vazio após um teste, verifique se o processo em análise foi efetivamente executado e se houve tempo suficiente entre o processo e a verificação. Repita o teste em condições documentadas e compare com o resultado inicial guardado. Mesmo assim, um relatório vazio tem as suas limitações: nem todas as alocações nem todas as referências relevantes são detetadas pelo kmemleak.

Guarde os resultados existentes antes de efetuar alterações no estado do diagnóstico. A saída pode conter endereços internos e outras informações sensíveis; trate-a de acordo com as regras de acesso e publicação do seu ambiente. Execute as etapas que alteram o estado, de preferência, num sistema de teste isolado e autorizado, e tenha em conta o esforço adicional de diagnóstico, sem assumir um valor percentual não especificado.

Uma elevada necessidade de memória ou Pressão de memória trata-se de um problema operacional independente e, por si só, não constitui prova de uma fuga no kernel. Para a análise dos tempos de espera e da escassez de memória, o artigo sobre Pressão de memória no kernel do Linux. Combina essas observações operacionais com uma análise específica dos códigos e dos resultados, em vez de deduzir diretamente a causa a partir de uma curva RAM.

Escolher a ferramenta de diagnóstico adequada

Escolhe a ferramenta de acordo com a suspeita Classe de erro, e não apenas com base no sintoma geral do aumento da utilização da memória. O kmemleak procura objetos do kernel suportados que possam estar órfãos. Para acessos inválidos ou problemas de memória de um processo de utilizador, é aconselhável utilizar outra instrumentação; as ferramentas respondem a questões diferentes.

A suspeita de uma referência perdida ao kernel aponta, em primeiro lugar, para o kmemleak. Por outro lado, se um erro indicar um acesso fora de um objeto ou a memória já libertada, o KASAN é adequado para a análise desta classe. O KFENCE também monitoriza determinados erros de memória, mas utiliza uma abordagem de instrumentação diferente; a disponibilidade e a adequação dependem do kernel específico e do ambiente de teste.

Se houver suspeita de um processo no espaço do utilizador, analise a sua memória com uma ferramenta específica para o efeito, como o Valgrind Memcheck. Um relatório do kmemleak sobre objetos do kernel não substitui uma análise da pilha de uma aplicação. Por outro lado, uma indicação proveniente de um processo do espaço de utilizador não explica automaticamente se um módulo do kernel está a perder memória.

Para continuar o trabalho, escolhe um teste reproduzível e registe a compilação do kernel, a configuração e o fluxo de execução. Analise o ciclo de vida do objeto em questão no código, corrija a causa identificada e repita o mesmo fluxo de execução em condições tão semelhantes quanto possível. Compare novamente os resultados; o facto de não ter surgido qualquer mensagem não prova, por si só, que o sistema esteja totalmente isento de erros.