Kernel-geheugenlekken opsporen en onderzoeken met kmemleak

Wat kmemleak in de kernel detecteert

Kmemleak ondersteunt het debuggen van de Linux-kernel door te zoeken naar mogelijk verweesde geheugenobjecten. Hiervoor volgt het ondersteunde toewijzingen en controleert het of er vanuit gescande geheugengebieden verwijzingen naar deze objecten te herkennen zijn. Een object dat niet als bereikbaar wordt herkend, wordt weergegeven als een mogelijk geheugenlek, niet als een definitief bewezen fout.

Stel je voor dat een kernelmodule een object reserveert en vervolgens de laatste verwijzing ernaar kwijtraakt, zonder het geheugen vrij te geven. Als kmemleak tijdens zijn Zoeken naar referenties Als er geen verwijzing meer naar het object is, kan het dit als verdacht melden. De melding biedt een aanknopingspunt om de toewijzing en de beoogde levenscyclus in de code te onderzoeken.

De procedure lijkt op het bereikbaarheidsonderzoek van een garbage collector, maar neemt de opruiming daarvan niet over: Kmemleak maakt gemelde objecten niet vrij en herstelt geen code. Of een object daadwerkelijk verloren is, moet worden vastgesteld aan de hand van het gebruik ervan, de eigendomsverhoudingen en de beoogde vrijgave.

Een kernel-lek heeft betrekking op geheugen dat door de kernelcode of een module wordt beheerd. Een lek in een PHP-dienst of een ander user-space-proces valt onder een andere categorie fouten; kmemleak onderzoekt de heap daarvan niet. Voor de bredere Detectie van geheugenlekken bij hostingactiviteiten Daarom komen ook procesgegevens en andere diagnosehulpmiddelen in aanmerking.

Een toename van het RAM-gebruik op zich bewijst nog niet dat er sprake is van een Geheugenlek noch de locatie ervan. Ook een gewijzigde omvang van de werkzaamheden of gegevens die langer worden bewaard, kunnen de behoefte beïnvloeden. Een zinvol uitgangspunt is daarom een qua tijd en functie afbakbaar proces, waarbij een vermoeden van een kernel gericht kan worden onderzocht.

Waarom meldingen verdachte gevallen blijven

Het zoeken naar pointerwaarden kan niet elke betekenis herkennen die een programma aan een referentie toekent. Als een geldige referentie buiten de gescande gebieden ligt of zodanig is opgeslagen dat kmemleak deze niet herkent, kan een object dat nog steeds nodig is als ‘verweesd’ worden weergegeven. Dit is een mogelijke Vals alarm: Het bericht op zich bewijst nog niet dat de goedkeuring ontbreekt.

Het tegenovergestelde is ook mogelijk. Een getal kan er toevallig uitzien als een pointer naar een object, hoewel de code het niet als referentie gebruikt. Kmemleak kan het object dan als bereikbaar classificeren en een daadwerkelijk lek over het hoofd zien. Een lege uitvoer is daarom geen bewijs dat de onderzochte code foutloos is.

Daarnaast is er de omvang van de toegewezen geheugenblokken: directe paginatoewijzingen en ioremap worden volgens de kernel-documentatie niet bijgehouden. Wie een toename van het geheugengebruik in deze gebieden vermoedt, kan uit een onopvallend kmemleak-rapport niet concluderen dat er geen reden tot bezorgdheid is voor de betreffende oorzaak. Daarvoor is een ander soort onderzoek nodig.

De Toegankelijkheid Het is dus een technische heuristiek en geen volledige semantische analyse van het programma. Het geeft geen betrouwbaar antwoord op de vraag of een gedetecteerde verwijzing op de juiste manier wordt gebruikt of dat een over het hoofd geziene verwijzing daadwerkelijk ontbreekt. Een enkele vondst is een controleopdracht; het ontbreken van vondsten beperkt slechts de uitspraak van de betreffende scan.

Voor de beoordeling is het de moeite waard om een vermoeden onder gecontroleerde omstandigheden opnieuw te simuleren en vervolgens het bijbehorende codepad te bekijken. Er moet met name worden opgehelderd wie de eigenaar van het object is en wanneer het zou moeten worden vrijgegeven. Alleen dit onderzoek kan een plausibele verklaring voor de bevinding opleveren.

Testomgeving en vereisten controleren

De gedateerde documentatie voor Linux 6.6 dient hier als technische uitgangspunt. Of kmemleak daadwerkelijk beschikbaar is op jouw systeem, hangt echter af van de gebruikte kernelbuild en de configuratie daarvan, en niet alleen van het versienummer. Controleer daarom welke distributiekernel er concreet is geïnstalleerd en noteer de build en configuratie voor latere analyse.

Een voorwaarde is de ingecompileerde kerneloptie CONFIG_DEBUG_KMEMLEAK. Los daarvan is de Activering tijdens de looptijd: Is de kernel gecompileerd met CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF geconfigureerd, kan de opstartparameter kmemleak=on nodig zijn. Houd uitdrukkelijk rekening met wijzigingen in het opstartproces voor de goedgekeurde testconfiguratie.

Om toegang te krijgen tot de diagnose-interface moet bovendien debugfs beschikbaar zijn en op de juiste manier zijn geïntegreerd. Kernelconfiguratie, activering en toegang tot het bestandssysteem zijn verschillende controlepunten: het ontbreken van één interface alleen zegt nog niet welke daarvan de oorzaak is. Voor de toegang kunnen speciale rechten nodig zijn.

Gebruik indien mogelijk een geïsoleerde VM of een speciaal testsysteem en vraag vooraf toestemming voor wijzigingen. Kmemleak zorgt voor extra belasting bij toewijzingen en vrijgaven; het effect hangt af van de omgeving en de belasting. Zonder de juiste metingen kan hiervoor geen algemeen geldende prestatievermindering worden aangegeven.

Documenteer naast de kernel ook de onderzochte module, het geplande verloop en het tijdstip van de uitvoer. Diagnoserapporten kunnen interne adressen en andere gevoelige informatie bevatten. Bewaar ze op een plek met beperkte toegang en controleer, voordat je ze doorgeeft, welke gegevens daadwerkelijk nodig zijn voor de foutanalyse.

Interface en diagnosecommando's

Begin op het vrijgegeven testsysteem met leestoegang tot /sys/kernel/debug/kmemleak. Het bestand toont de momenteel gemelde verdachte gevallen. Toegang hiertoe kan speciale rechten vereisen; een lege uitvoer geeft alleen de zichtbare diagnosestatus weer en bewijst niet dat de kernel vrij is van geheugenlekken.

Voer de volgende opdracht uit in een shell met voldoende leesrechten. Deze opdracht heeft geen invloed op de diagnosestatus en is ook geschikt om een eerste bevinding vast te leggen voordat je verdere stappen onderneemt.

cat /sys/kernel/debug/kmemleak

Als het bestand ontbreekt, zijn er drie mogelijke oorzaken: de kernel is mogelijk zonder CONFIG_DEBUG_KMEMLEAK gebouwd, kmemleak is tijdens de uitvoering niet geactiveerd of debugfs is niet op de verwachte locatie gemount. Het ontbrekende bestand alleen geeft niet aan welk van beide het geval is. Controleer daarom de buildconfiguratie, de opstartconfiguratie en de mount afzonderlijk.

In de tabel wordt bewust onderscheid gemaakt tussen lezen en Schrijftoegang: Een scan en het opschonen van de zichtbare lijst hebben invloed op de diagnosestatus. Ook het eventueel noodzakelijke koppelen van debugfs heeft invloed op het systeem. Voer dergelijke stappen alleen uit met toestemming en de daarvoor benodigde rechten; het omleiden van schrijfopdrachten vereist eveneens voldoende rechten.

Verdachte gevallen op reproduceerbare wijze inperken

Zorg er eerst voor dat je de volledige uitvoer van de interface vastlegt, samen met het tijdstip, de kernelbuild en de testconfiguratie. Reeds aanwezige meldingen maken deel uit van de Uitgangsbevinding en mogen niet zomaar aan de volgende test worden toegeschreven. Bewaar de afdruk op een veilige plek, aangezien deze interne adressen en andere diagnostische informatie kan bevatten.

Op een vrijgegeven testsysteem kun je vervolgens de momenteel zichtbare meldingen met de volgende shell-opdracht uit de lijst met verdachte items verwijderen. De shell heeft schrijfrechten voor de interface nodig. De opdracht maakt geen geheugenblokken vrij en lost de oorzaak niet op; zonder voorafgaande back-up kunnen belangrijke aanwijzingen verloren gaan.

echo clear > /sys/kernel/debug/kmemleak

Start daarna een zo nauw mogelijk afgebakende en gedocumenteerde procedure, bijvoorbeeld het initialiseren en gecontroleerd opschonen van een te onderzoeken module. Leg vast welke stappen zijn uitgevoerd en wanneer deze zijn voltooid. Zo kan een latere vondst concreter worden vergeleken met het proces, zonder dat de tijdsnabijheid op zich al een oorzakelijk verband aantoont.

Start na het verstrijken van de tijd een scan in een shell met de juiste rechten en lees vervolgens de interface opnieuw in. Voor beide commando’s is het noodzakelijk dat kmemleak actief is en dat de debugfs-interface beschikbaar is.

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

Herhaal de procedure op een gecontroleerde manier en geef het voldoende tijd. Een scan hoeft niet meteen een reproduceerbaar resultaat op te leveren. Vergelijk voor een regressietest dezelfde test vóór en na de wijziging in de code, bij een zo veel mogelijk gelijkblijvende kernelconfiguratie en belasting; documenteer eventuele resterende verschillen. Een nieuw vermoeden ondersteunt een hypothese, maar vervangt niet de controle van de levenscyclus van het object.

Moduultest en evaluatie van de bevindingen

Bij een moduultest kun je bijvoorbeeld een initialisatiepad uitvoeren en vervolgens het daarvoor bestemde opruimpad doorlopen. Als er daarna een nieuwe vermelding verschijnt, noteer dan eerst de objectgrootte, de leeftijd en de procescontext, evenals de bijbehorende teststappen. Deze gegevens helpen bij het toewijzen van bevindingen; op zichzelf geven ze nog niet aan of het object daadwerkelijk had moeten worden vrijgegeven.

De Allocatie-stacktrace leidt naar de plek waar geheugen is aangevraagd. Van daaruit volg je in de code wie het object overneemt en via welk pad het weer moet worden vrijgegeven. De trace hoeft niet de plek te bevatten waar het vrijgeven is achterwege gebleven: toewijzing en het nalaten van het opruimen kunnen in verschillende functies plaatsvinden.

Houd ook rekening met de Toewijzingsvolgorde: De documentatie beschrijft de uitvoer in deze volgorde. Een eerder verweesd object kan nog meer meldingen tot gevolg hebben. Controleer daarom of meerdere vermeldingen tot hetzelfde objectcomplex of foutpad behoren, voordat je ze als afzonderlijke defecten telt.

Voor een optionele functietest wordt de module beschreven in de huidige kernel-documentatie kmemleak-test, dat opzettelijk geheugenlekken veroorzaakt. Gebruik het uitsluitend in een geïsoleerde testomgeving en controleer vooraf of het in de betreffende kernel beschikbaar is en correct is geconfigureerd. De huidige documentatie biedt geen garantie dat het beschikbaar is voor elke oudere of distributiespecifieke kernel.

Ook bij deze diagnosemodule is een onmiddellijke melding of een treffer bij de eerste scan niet gegarandeerd. Noteer het tijdstip van de test en de volgorde van de scans en herhaal het onderzoek op een gecontroleerde manier. Als de uitvoer in eerste instantie leeg blijft, controleer dan de voorwaarden en de procedure, in plaats van daaruit alleen maar te concluderen dat de diagnoseomgeving al dan niet goed functioneert.

De oorzaak onderzoeken in plaats van de melding te verbergen

Begin bij een verdacht geval met de levenscyclus van het gemelde object: welke functie reserveert het, wie neemt vervolgens de verantwoordelijkheid op zich en wanneer moet het worden vrijgegeven? De allocatie-stacktrace leidt je naar de bron van de reservering. Of er daar of op een later punt een fout zit, kun je pas beoordelen aan de hand van het codepad.

Let vooral op de Eigendomsverhoudingen bij overdrachten tussen functies en modules. Als een referentie wordt doorgegeven, moet duidelijk zijn welke kant deze behoudt en welke kant de vrijgave uitvoert. Vergelijk bovendien het reguliere afwikkelingspad met afbreek- en foutpaden, bijvoorbeeld wanneer een initialisatie slechts gedeeltelijk wordt voltooid.

Er kan ook een foutmelding verschijnen, ook al bestaat er een geldige referentie die kmemleak niet herkent. Controleer daarom, voordat je de foutmelding onderdrukt, waar en in welke vorm de pointer wordt opgeslagen. Leg vast waarom het object gedurende zijn beoogde levensduur bereikbaar blijft en op welke manier het uiteindelijk wordt vrijgegeven.

Voor geteste uitzonderingsgevallen staan ontwikkelaars Aantekeningen beschikbaar: kmemleak_not_leak markeert een bekend object als geen lek, maar blijft het wel scannen op verwijzingen. kmemleak_ignore sluit het object zowel uit de melding als uit de scan uit. Daardoor kunnen verwijzingen die daarin zijn opgenomen, ontbreken in de analyse.

Controleer de beschikbaarheid en semantiek van de API in de kernel die daadwerkelijk wordt gebruikt; de huidige API-documentatie is niet automatisch een garantie voor elke oudere build. Een annotatie lost noch een ontbrekende vrijgave, noch een foutieve eigendomsoverdracht op. Gebruik deze daarom niet als enige middel om een storende uitvoer te laten verdwijnen.

Foutopsporing en veilige werking

Ontbreekt het bestand? /sys/kernel/debug/kmemleak, controleer eerst de daadwerkelijk gestarte kernel-build en de configuratie daarvan. CONFIG_DEBUG_KMEMLEAK moet aanwezig zijn; het versienummer van een distributie alleen is hiervoor niet voldoende. Noteer de build en de configuratie, zodat latere vergelijkingen op dezelfde basis kunnen plaatsvinden.

Controleer daarnaast ook de Activering tijdens de looptijd en de integratie van debugfs. Bij CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF kan de opstartparameter kmemleak=on kan nodig zijn. Een ontbrekend bestand maakt zelf geen onderscheid tussen deze mogelijke oorzaken; wijzigingen in het opstartproces of het koppelen van debugfs horen thuis in een goedgekeurde testconfiguratie.

Als de uitvoer na een test leeg blijft, controleer dan of het onderzochte proces daadwerkelijk is uitgevoerd en of er voldoende tijd zat tussen het proces en de scan. Herhaal de test onder gedocumenteerde omstandigheden en vergelijk de resultaten met de opgeslagen uitgangsgegevens. Ook dan blijft een leeg rapport beperkt: niet elke toewijzing en niet elke relevante verwijzing wordt door kmemleak geregistreerd.

Sla bestaande bevindingen op voordat je wijzigingen aanbrengt in de diagnosestatus. De uitvoer kan interne adressen en andere gevoelige informatie bevatten; behandel deze informatie volgens de toegangs- en publicatieregels van jouw omgeving. Voer stappen die de status wijzigen bij voorkeur uit op een geïsoleerd, vrijgegeven testsysteem en houd rekening met de extra diagnostische inspanning, zonder hiervoor een ongefundeerd percentage aan te nemen.

Een hoge opslagbehoefte of Geheugendruk is een op zichzelf staand systeemprobleem en op zich geen bewijs van een kernellek. Voor het duiden van wachttijden en geheugentekorten biedt het artikel over Geheugendruk in de Linux-kernel. Combineer dergelijke bedrijfswaarnemingen met een gerichte controle van de code en de bevindingen, in plaats van direct uit een RAM-curve conclusies te trekken over de oorzaak.

Het juiste diagnose-instrument kiezen

Kies het gereedschap op basis van de vermoedelijke Foutklasse, niet alleen op basis van het algemene symptoom van toenemend geheugengebruik. kmemleak zoekt naar mogelijk verweesde, ondersteunde kernelobjecten. Voor ongeldige toegangen of geheugenproblemen van een gebruikersproces is een andere instrumentatie zinvol; de tools geven antwoord op verschillende vragen.

Een vermoeden van een verloren kernelreferentie wijst in eerste instantie op kmemleak. Als een foutbeeld daarentegen wijst op toegang buiten een object of op reeds vrijgegeven geheugen, is KASAN geschikt voor het onderzoeken van deze klasse. KFENCE volgt eveneens bepaalde geheugenfouten, maar maakt gebruik van een andere instrumentatieaanpak; de beschikbaarheid en geschiktheid hangen af van de specifieke kernel en de testomgeving.

Als het vermoeden op een user-space-proces rust, onderzoek dan het geheugen daarvan met een daarvoor bestemd hulpprogramma zoals Valgrind Memcheck. Een kmemleak-rapport over kernelobjecten is geen vervanging voor een analyse van de heap van een toepassing. Omgekeerd betekent een melding vanuit een gebruikersproces niet automatisch dat een kernelmodule geheugen verliest.

Kies er een uit voor het verdere werk reproduceerbare test en leg de kernelbuild, configuratie en het verloop vast. Onderzoek de gemelde levenscyclus van het object in de code, corrigeer een aangetoonde oorzaak en herhaal hetzelfde verloop onder zo gelijk mogelijke omstandigheden. Vergelijk de bevindingen opnieuw; het uitblijven van een melding op zich bewijst nog niet dat het systeem volledig foutloos is.