Détecter et analyser les fuites de mémoire du noyau à l'aide de kmemleak

Ce que kmemleak détecte dans le noyau

Kmemleak Il facilite le débogage du noyau Linux en recherchant des objets mémoire potentiellement orphelins. Pour ce faire, il suit les allocations prises en charge et vérifie si des références à ces objets sont détectables dans les zones de mémoire analysées. Un objet non identifié comme accessible apparaît comme une fuite potentielle, et non comme une erreur définitivement avérée.

Imagine qu'un module du noyau réserve un objet puis perde la dernière référence à celui-ci sans libérer la mémoire. Si kmemleak, lors de son Recherche de références s'il n'y a plus aucune référence à l'objet, il peut le signaler comme suspect. Ce signalement fournit un point de départ pour examiner son allocation et son cycle de vie prévu dans le code.

Le processus s'apparente à la recherche d'accessibilité effectuée par un ramasse-miettes, mais ne prend pas en charge le nettoyage : Kmemleak ne libère pas les objets signalés et ne corrige pas le code. Pour déterminer si un objet est réellement perdu, il faut examiner son utilisation, ses relations de propriété et la libération prévue.

Une fuite du noyau concerne la mémoire gérée par le code du noyau ou par un module. Une fuite dans un service PHP ou dans un autre processus de l'espace utilisateur relève d'une autre catégorie d'erreurs ; kmemleak n'analyse pas son tas. Pour une approche plus large, Détection des fuites de mémoire dans les services d'hébergement Il faut donc également envisager les données de processus et d'autres outils de diagnostic.

L'augmentation de l'utilisation de la mémoire vive ne prouve pas à elle seule un Fuite de mémoire ni son emplacement. Une modification du périmètre des tâches ou une conservation prolongée des données peuvent également influencer les besoins. Un bon point de départ consiste donc à définir un scénario délimité dans le temps et sur le plan fonctionnel, permettant d'examiner de manière ciblée un soupçon lié au noyau.

Pourquoi les signalements restent des cas suspects

La recherche de valeurs de pointeurs ne permet pas de détecter toutes les significations qu'un programme attribue à une référence. Si une référence valide se trouve en dehors des zones analysées ou si elle est stockée d'une manière que kmemleak ne peut pas reconnaître, un objet dont on a encore besoin peut apparaître comme orphelin. C'est un cas de figure possible fausse alerte: Cette notification ne suffit pas à elle seule à prouver l'absence d'autorisation.

Le contraire est également possible. Une valeur numérique peut ressembler par hasard à un pointeur vers un objet, même si le code ne l'utilise pas en tant que référence. Kmemleak peut alors considérer l'objet comme accessible et passer à côté d'une fuite réelle. Une sortie vide ne prouve donc pas que le code analysé est exempt d'erreurs.

À cela s'ajoute l'étendue des allocations suivies : les allocations directes de pages et ioremap ne sont pas suivis, selon la documentation du noyau. Si l'on soupçonne une augmentation de la mémoire dans ces zones, on ne peut pas conclure, à partir d'un rapport kmemleak anodin, que la cause en question n'est pas en cause. Une analyse différente est nécessaire à cet effet.

Le Accessibilité Il s'agit donc d'une heuristique technique et non d'une analyse sémantique complète du programme. Elle ne permet pas de déterminer de manière fiable si une référence détectée est utilisée à bon escient ou si une référence non détectée fait réellement défaut. Chaque résultat correspond à une tâche de vérification ; l'absence de résultats ne fait que limiter la portée de l'analyse concernée.

Pour l'évaluation, il est utile de reproduire le phénomène suspect dans des conditions contrôlées, puis d'examiner le chemin d'exécution correspondant. Il convient notamment de déterminer à qui appartient l'objet et à quel moment il devrait être libéré. Seule cette analyse peut fournir une explication plausible du résultat observé.

Vérifier l'environnement de test et les conditions préalables

La documentation versionnée pour Linux 6.6 sert ici de base technique. Cependant, la disponibilité effective de kmemleak sur votre système dépend de la version du noyau utilisée et de sa configuration, et pas uniquement du numéro de version. Vérifie donc le noyau de distribution concrètement installé et note la version et la configuration en vue d'une analyse ultérieure.

Une condition préalable est que l'option du noyau soit intégrée à la compilation CONFIG_DEBUG_KMEMLEAK. Il faut distinguer de cela la activation à l'exécution: Le noyau est-il compilé avec CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF une fois configuré, le paramètre de démarrage kmemleak=on peut s'avérer nécessaire. Prévoyez expressément les modifications apportées au processus de démarrage pour la configuration de test validée.

Pour accéder à l'interface de diagnostic, il faut également debugfs être disponible et correctement intégrée. La configuration du noyau, l'activation et l'accès au système de fichiers constituent autant de points de contrôle distincts : l'absence d'une interface ne permet pas à elle seule de déterminer laquelle de ces causes est en origine du problème. L'accès peut nécessiter des droits privilégiés.

Utilisez si possible une machine virtuelle isolée ou un système de test dédié, et obtenez au préalable l'autorisation d'effectuer des modifications. Kmemleak entraîne un surcroît de charge lors des allocations et des libérations ; l'impact dépend de l'environnement et de la charge. En l'absence de mesures appropriées, il n'est pas possible d'indiquer une perte de performances générale.

Outre le noyau, documentez également le module examiné, le déroulement prévu et le moment de la sortie. Les rapports de diagnostic peuvent contenir des adresses internes et d'autres informations sensibles. Conservez-les dans un emplacement à accès restreint et, avant de les transmettre, vérifiez quelles informations sont réellement nécessaires à l'analyse des erreurs.

Interface et commandes de diagnostic

Sur le système de test partagé, commencez par un accès en lecture à /sys/kernel/debug/kmemleak. Ce fichier répertorie les cas suspects actuellement signalés. Son accès peut nécessiter des droits privilégiés ; une sortie vide décrit uniquement l'état de diagnostic visible et ne prouve pas que le noyau ne présente aucune fuite de mémoire.

Exécutez la commande suivante dans un terminal disposant de droits de lecture suffisants. Elle ne modifie pas l'état de diagnostic et permet également de sauvegarder un premier bilan avant de passer à l'étape suivante.

cat /sys/kernel/debug/kmemleak

Si le fichier est manquant, il existe trois causes possibles : le noyau a peut-être été compilé sans CONFIG_DEBUG_KMEMLEAK compilé, kmemleak n'est pas activé lors de l'exécution ou debugfs n'est pas monté à l'emplacement prévu. L'absence du fichier ne permet pas à elle seule de déterminer laquelle de ces deux causes est en cause. Vérifie donc séparément la configuration de compilation, la configuration de démarrage et le montage.

Le tableau établit délibérément une distinction entre la lecture et Droits d'écriture: Une analyse et le nettoyage de la liste visible modifient l'état du diagnostic. Le montage de debugfs, si nécessaire, modifie également le système. N'effectuez ces opérations qu'avec l'autorisation et les droits requis ; la redirection des commandes d'écriture nécessite également des droits suffisants.

Déterminer de manière reproductible les cas suspects

Commence par enregistrer la sortie complète de l'interface, en précisant l'heure, la version du noyau et la configuration de test. Les messages déjà présents font partie du Bilan initial et ne doivent pas être attribués sans comparaison au test suivant. Conservez cette sortie en lieu sûr, car elle peut contenir des adresses internes et d'autres informations de diagnostic.

Sur un système de test mis en production, tu peux ensuite retirer de la liste des éléments suspects les messages actuellement visibles à l'aide de la commande shell suivante. Le shell doit disposer des droits d'écriture sur l'interface. Cette commande ne libère pas de blocs de mémoire et ne résout pas la cause du problème ; sans sauvegarde préalable, des informations importantes pourraient être perdues.

echo clear > /sys/kernel/debug/kmemleak

Lance ensuite une procédure aussi ciblée et documentée que possible, par exemple l'initialisation et le nettoyage contrôlé d'un module à analyser. Notez les étapes qui ont été effectuées et à quel moment elles ont été achevées. Cela permettra de recouper plus précisément une découverte ultérieure avec le déroulement des opérations, sans que la simple proximité temporelle ne suffise à prouver un lien de causalité.

Une fois le délai écoulé, lancez une analyse dans un shell disposant des droits nécessaires, puis relisez l'interface. Ces deux commandes supposent que kmemleak soit actif et que l'interface debugfs soit disponible.

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

Répétez la procédure de manière contrôlée et accordez-lui suffisamment de temps. Un scan ne fournit pas nécessairement un résultat reproductible dès le premier essai. Pour vérifier s'il y a eu régression, comparez le même test avant et après la modification du code, en veillant à ce que la configuration du noyau et la charge soient aussi identiques que possible ; documentez les différences persistantes. Une nouvelle suspicion vient étayer une hypothèse, mais ne remplace pas la vérification du cycle de vie de l'objet.

Test du module et analyse des résultats

Lors d'un test de module, tu peux par exemple exécuter un chemin d'initialisation, puis faire parcourir le chemin de nettoyage prévu. Si une nouvelle entrée apparaît par la suite, note d’abord la taille de l’objet, son âge et le contexte du processus, ainsi que les étapes de test associées. Ces informations aident à attribuer les résultats ; à elles seules, elles ne permettent pas encore de déterminer si l’objet aurait effectivement dû être validé.

Le Trace de pile d'allocation te mène à l'endroit où la mémoire a été allouée. À partir de là, tu peux suivre dans le code qui prend en charge l'objet et quel chemin doit le libérer. La trace ne doit pas nécessairement contenir l'endroit où une libération n'a pas eu lieu : l'allocation et le nettoyage manqué peuvent se situer dans des fonctions différentes.

Pense également à la Ordre d'allocation: La documentation décrit les messages dans cet ordre. Un objet orphelin antérieur peut entraîner d'autres messages. Vérifie donc si plusieurs entrées appartiennent au même ensemble d'objets ou au même chemin d'erreur avant de les compter comme des défauts indépendants.

Pour un test de fonctionnement facultatif, la documentation actuelle du noyau décrit le module kmemleak-test, qui génère délibérément des fuites de mémoire. Utilisez-le exclusivement dans un environnement de test isolé et vérifiez au préalable s’il est disponible dans le noyau concerné et s’il est configuré en conséquence. La documentation actuelle, qui est susceptible d’évoluer, ne garantit pas sa disponibilité pour tous les noyaux plus anciens ou spécifiques à certaines distributions.

Même avec ce module de diagnostic, il n'est pas garanti qu'un message s'affiche immédiatement ou qu'un résultat soit obtenu dès le premier scan. Notez l'heure du test et la séquence de scan, puis répétez l'examen de manière contrôlée. Si le résultat reste vide dans un premier temps, vérifiez les conditions préalables et la procédure, plutôt que d'en conclure automatiquement que l'environnement de diagnostic fonctionne correctement ou est défectueux.

Vérifier la cause plutôt que de masquer le message

En cas de suspicion, commence par examiner le cycle de vie de l'objet signalé : quelle fonction réserve-t-il, qui en assume ensuite la responsabilité et quand doit-il être libéré ? La trace de pile d'allocation vous mène à l'origine de la réservation. Ce n'est qu'en examinant le chemin du code que l'on peut déterminer si l'erreur se situe à cet endroit ou plus loin.

Vérifie en particulier les Structure de l'actionnariat lors des transferts entre fonctions et modules. Lorsqu’une référence est transmise, il faut préciser clairement quelle partie la conserve et quelle partie procède à sa libération. Comparez également le chemin de nettoyage normal aux chemins d’interruption et d’erreur, par exemple lorsqu’une initialisation n’est que partiellement terminée.

Un message d'erreur peut également s'afficher alors qu'il existe une référence valide que kmemleak ne détecte pas. Avant de le supprimer, vérifie donc où et sous quelle forme le pointeur est stocké. Explique pourquoi l'objet reste accessible pendant toute sa durée de vie prévue et comment il est finalement libéré.

Pour les cas particuliers vérifiés, les développeurs disposent de Annotations disponible : kmemleak_not_leak marque un objet connu comme n'étant pas une fuite, mais continue à analyser ses références. kmemleak_ignore exclut l'objet à la fois du rapport et de l'analyse. De ce fait, certaines références qu'il contient peuvent ne pas apparaître dans l'analyse.

Vérifie la disponibilité et la sémantique de l'API dans le noyau réellement utilisé ; la documentation actuelle de l'API ne garantit pas automatiquement sa compatibilité avec toutes les anciennes versions. Une annotation ne corrige ni l'absence d'autorisation ni un changement de propriété erroné. Ne l'utilisez donc pas uniquement pour faire disparaître un message gênant.

Dépannage et fonctionnement en toute sécurité

Le fichier est-il manquant ? /sys/kernel/debug/kmemleak, vérifie d'abord la version du noyau effectivement lancée et sa configuration. CONFIG_DEBUG_KMEMLEAK doit être disponible ; le numéro de version d'une distribution ne suffit pas à lui seul. Notez la version et la configuration afin que les comparaisons ultérieures puissent s'effectuer sur une base commune.

Vérifie séparément la activation à l'exécution et l'intégration de debugfs. Dans le cas de CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF le paramètre de démarrage kmemleak=on peut s'avérer nécessaire. Un fichier manquant ne permet pas de distinguer ces causes possibles ; les modifications apportées au processus de démarrage ou le montage de `debugfs` doivent être effectuées dans une configuration de test validée.

Si le résultat reste vide après un test, vérifiez si le processus examiné a bien été exécuté et s'il y a eu suffisamment de temps entre l'exécution du processus et l'analyse. Répétez l'opération dans des conditions documentées et comparez les résultats avec ceux enregistrés initialement. Même dans ce cas, un rapport vide a ses limites : kmemleak ne détecte pas toutes les allocations ni toutes les références pertinentes.

Sauvegardez les résultats existants avant d'apporter des modifications à l'état diagnostique. La sortie peut contenir des adresses internes et d'autres informations sensibles ; traitez-la conformément aux règles d'accès et de publication de votre environnement. Effectuez de préférence les opérations modifiant l'état sur un système de test isolé et validé, et tenez compte de l'effort de diagnostic supplémentaire sans pour autant supposer un pourcentage non justifié.

Des besoins importants en mémoire ou Pression mémoire Il s'agit d'un problème de fonctionnement distinct qui, en soi, ne constitue pas une preuve de fuite du noyau. Pour mieux comprendre les temps d'attente et les problèmes de mémoire insuffisante, l'article sur Pression mémoire dans le noyau Linux. Associez ces observations de fonctionnement à une analyse ciblée du code et des résultats, plutôt que de tirer des conclusions sur la cause directement à partir d'une courbe RAM.

Choisir l'outil de diagnostic adapté

Choisis l'outil en fonction de la cause présumée Catégorie d'erreurs, et pas uniquement en se basant sur le symptôme général d'une utilisation croissante de la mémoire. kmemleak recherche les objets du noyau pris en charge qui pourraient être orphelins. Pour détecter les accès non valides ou les problèmes de mémoire d'un processus utilisateur, il est préférable d'utiliser un autre outil d'instrumentation ; ces outils répondent à des questions différentes.

Une suspicion de référence perdue au noyau laisse d'abord penser à kmemleak. En revanche, si un profil d'erreur indique un accès en dehors d'un objet ou à de la mémoire déjà libérée, KASAN est adapté à l'analyse de ce type de problème. KFENCE suit également certaines erreurs de mémoire, mais utilise une approche d'instrumentation différente ; sa disponibilité et son adéquation dépendent du noyau concerné et de l'environnement de test.

Si la suspicion porte sur un processus de l'espace utilisateur, analysez sa mémoire à l'aide d'un outil prévu à cet effet, tel que Valgrind Memcheck. Un rapport kmemleak concernant des objets du noyau ne remplace pas une analyse du tas d'une application. À l'inverse, une indication provenant d'un processus utilisateur ne permet pas automatiquement de déterminer si un module du noyau perd de la mémoire.

Pour la suite de ton travail, choisis un test reproductible et consigne la compilation du noyau, sa configuration et son déroulement. Examine le cycle de vie de l'objet signalé dans le code, corrige la cause identifiée et répète le même processus dans des conditions aussi identiques que possible. Comparez à nouveau les résultats ; l’absence de message ne prouve pas à elle seule l’absence totale d’erreurs.