Identificering og undersøgelse af kernel-hukommelseslækager med kmemleak

Hvad kmemleak registrerer i kernen

Kmemleak understøtter fejlfinding i Linux-kernen ved at søge efter potentielt forladte hukommelsesobjekter. Til dette formål sporer den understøttede allokeringer og kontrollerer, om der kan identificeres henvisninger til disse objekter i de scannede hukommelsesområder. Et objekt, der ikke genkendes som tilgængeligt, vises som en mulig lækage, ikke som en endeligt påvist fejl.

Forestil dig, at et kernemodul reserverer et objekt og derefter mister den sidste henvisning til det uden at frigive hukommelsen. Hvis kmemleak under sin Søgning efter referencer Hvis der ikke længere er nogen henvisning til objektet, kan det rapportere dette som mistænkeligt. Rapporten giver et udgangspunkt for at undersøge allokeringen og den forventede livscyklus i koden.

Metoden ligner en garbage collectors søgning efter tilgængelige objekter, men overtager ikke dens oprydning: Kmemleak frigiver ikke rapporterede objekter og reparerer ikke koden. Om et objekt rent faktisk er gået tabt, skal afgøres ud fra dets anvendelse, ejerskabsforhold og den planlagte frigivelse.

En kernel-lækage vedrører hukommelse, der administreres af kernelkoden eller et modul. En lækage i en PHP-tjeneste eller en anden brugerproces er en anden fejltype; kmemleak undersøger ikke dens heap. For den bredere Påvisning af hukommelseslækager i hostingdriften Derfor kan procesdata og andre diagnoseværktøjer også komme i betragtning.

En stigende RAM-udnyttelse i sig selv beviser hverken en Hukommelseslækage eller hvor det finder sted. Også ændringer i arbejdsomfanget eller data, der opbevares i længere tid, kan påvirke behovet. Et fornuftigt udgangspunkt er derfor en proces, der kan afgrænses tidsmæssigt og funktionelt, og hvor en mistanke om en kernel kan undersøges målrettet.

Hvorfor forbliver indberetninger blot mistænkte tilfælde

Søgningen efter pointerværdier kan ikke genkende alle de betydninger, som et program tillægger en reference. Hvis en gyldig reference ligger uden for de scannede områder, eller hvis den er gemt på en måde, så kmemleak ikke kan genkende den, kan et objekt, der stadig er nødvendigt, fremstå som forladt. Dette er en mulig Falsk alarm: Meddelelsen i sig selv er ikke bevis for, at godkendelsen mangler.

Det modsatte er også muligt. Et tal kan tilfældigvis ligne en pointer til et objekt, selvom koden ikke bruger det som en reference. Kmemleak kan i så fald klassificere objektet som tilgængeligt og overse et egentligt læk. Et tomt resultat er derfor ikke et bevis på, at den undersøgte kode er fejlfri.

Hertil kommer omfanget af de allokeringer, der foretages: Direkte sideallokeringer og ioremap Ifølge kerne-dokumentationen overvåges disse områder ikke. Hvis man formoder, at der er en stigning i hukommelsesforbruget i disse områder, kan man ikke ud fra en ubetydelig kmemleak-rapport konkludere, at den pågældende årsag er udelukket. Til det formål er der behov for en anden form for undersøgelse.

Die Tilgængelighed er altså en teknisk heuristik og ikke en fuldstændig semantisk analyse af programmet. Den giver ikke et pålideligt svar på, om en fundet henvisning anvendes hensigtsmæssigt, eller om en overset henvisning rent faktisk mangler. Et enkelt fund udgør en kontrolopgave; manglende fund begrænser blot konklusionen af den pågældende scanning.

Med henblik på vurderingen er det en god idé at genskabe en mistanke under kontrollerede forhold og derefter undersøge den tilhørende kodesti. Det skal især afklares, hvem der ejer objektet, og hvornår det bør frigives. Først denne undersøgelse kan give en plausibel forklaring på fundet.

Kontroller testmiljøet og forudsætningerne

Den versionsspecifikke dokumentation til Linux 6.6 fungerer her som fagligt udgangspunkt. Om kmemleak rent faktisk er tilgængeligt på dit system, afhænger dog af den anvendte kernel-build og dens konfiguration, ikke alene af versionsnummeret. Kontroller derfor den konkret installerede distributionskernel, og noter build og konfiguration til senere analyse.

En forudsætning er, at kernel-optionen er kompileret ind CONFIG_DEBUG_KMEMLEAK. Helt adskilt herfra er Aktivering under kørsel: Er kernen med CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF konfigureres, kan boot-parameteren kmemleak=on kan være nødvendigt. Sørg for udtrykkeligt at indregne ændringer i opstartsprocessen for den godkendte testkonfiguration.

For at få adgang til diagnosegrænsefladen skal man desuden debugfs skal være tilgængelig og integreret på passende vis. Kernelkonfiguration, aktivering og adgang til filsystemet er forskellige kontrolpunkter: En manglende grænseflade i sig selv afslører ikke, hvilket af disse der er årsagen. Der kan være behov for privilegerede rettigheder for at få adgang.

Brug om muligt en isoleret VM eller et dedikeret testsystem, og sørg for at få godkendelse til ændringer på forhånd. Kmemleak medfører ekstra arbejde i forbindelse med allokeringer og frigivelser; virkningen afhænger af miljøet og belastningen. Uden passende målinger er det ikke muligt at angive en generel ydelsesnedgang.

Udover kernen skal du også dokumentere det undersøgte modul, den planlagte afvikling og tidspunktet for udskriften. Diagnoserapporter kan indeholde interne adresser og andre følsomme oplysninger. Opbevar dem med begrænset adgang, og kontroller, inden du videregiver dem, hvilke oplysninger der rent faktisk er nødvendige for fejlanalysen.

Grænseflade og diagnosekommandoer

Start på det godkendte testsystem med læseadgang til /sys/kernel/debug/kmemleak. Filen viser aktuelt rapporterede mistænkelige tilfælde. Adgang kan kræve særlige rettigheder; et tomt output beskriver kun den synlige diagnosetilstand og beviser ikke, at kernen er fri for hukommelseslækager.

Udfør følgende kommando i en shell med tilstrækkelige læserettigheder. Den ændrer ikke diagnosestatus og er også velegnet til at gemme en foreløbig konklusion, inden der tages yderligere skridt.

cat /sys/kernel/debug/kmemleak

Hvis filen mangler, er der tre mulige årsager: Kernelen er muligvis blevet installeret uden CONFIG_DEBUG_KMEMLEAK bygget, kmemleak er ikke aktiveret under kørsel, eller debugfs er ikke monteret på det forventede sted. Den manglende fil alene afslører ikke, hvilket af disse punkter der er gældende. Kontroller derfor build-konfigurationen, boot-konfigurationen og monteringen hver for sig.

Tabellen skelner bevidst mellem læsning og Skriveadgang: En scanning og rydning af den synlige liste ændrer diagnosestatus. Også det eventuelt nødvendige tilkobling af debugfs ændrer systemet. Udfør kun sådanne trin med tilladelse og de nødvendige rettigheder; omdirigeringen ved skrivkommandoerne kræver ligeledes tilstrækkelige rettigheder.

At indkredse mistænkelige tilfælde på en reproducerbar måde

Sørg først for at gemme den komplette udskrift af grænsefladen sammen med tidspunkt, kernel-build og testkonfiguration. Allerede eksisterende meddelelser hører til Indledende undersøgelsesresultater og må ikke uden nærmere sammenligning tilskrives den følgende test. Opbevar udskriften på et sikkert sted, da den kan indeholde interne adresser og yderligere diagnostiske oplysninger.

På et godkendt testsystem kan du derefter fjerne de aktuelt synlige meddelelser fra listen over mistænkelige tilfælde ved hjælp af følgende shell-kommando. Shell’en skal have skriverettigheder til grænsefladen. Kommandoen frigiver ikke hukommelsesblokke og løser ikke årsagen; uden en forudgående sikkerhedskopiering kan vigtige oplysninger gå tabt.

echo clear > /sys/kernel/debug/kmemleak

Start derefter en så snævert afgrænset og dokumenteret procedure som muligt, f.eks. initialisering og kontrolleret oprydning af et modul, der skal undersøges. Notér, hvilke trin der blev udført, og hvornår de blev afsluttet. På den måde kan et senere fund sammenholdes mere konkret med forløbet, uden at den tidsmæssige nærhed i sig selv beviser en årsagssammenhæng.

Når tiden er udløbet, skal du starte en scanning i en shell med de nødvendige rettigheder og derefter læse grænsefladen igen. Begge kommandoer forudsætter, at kmemleak er aktivt, og at debugfs-grænsefladen er tilgængelig.

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

Gentag forløbet på en kontrolleret måde, og giv det tilstrækkelig tid. En scanning behøver ikke umiddelbart at give et reproducerbart resultat. Til en regression skal du sammenligne den samme test før og efter kodeændringen med så ens kernelkonfiguration og belastning som muligt; dokumenter eventuelle resterende forskelle. En ny mistanke underbygger en hypotese, men erstatter ikke kontrollen af objektets livscyklus.

Modultest og vurdering af resultaterne

Ved en modultest kan du for eksempel køre en initialiseringsrute og derefter lade den forudbestemte oprydningsrute køre igennem. Hvis der derefter dukker en ny post op, skal du først notere objektets størrelse, alder og proceskontekst samt de tilhørende testtrin. Disse oplysninger hjælper med at tilordne fundene; de viser i sig selv endnu ikke, om objektet faktisk burde have været frigivet.

Der Allokerings-stacktrace fører til det sted, hvor der blev anmodet om hukommelse. Derfra kan du i koden spore, hvem der overtager objektet, og hvilken sti der skal frigive det igen. Sporingerne behøver ikke at indeholde det sted, hvor frigivelsen ikke fandt sted: Allokering og manglende oprydning kan forekomme i forskellige funktioner.

Tag også højde for Allokeringsrækkefølge: Dokumentationen beskriver udskriften i denne rækkefølge. Et tidligere forladt objekt kan medføre yderligere meddelelser. Kontroller derfor, om flere poster hører til den samme objektgruppe eller fejlsti, før du tæller dem som uafhængige fejl.

Med henblik på en valgfri funktionstest beskriver den aktuelle kerne-dokumentation modulet kmemleak-test, der bevidst skaber hukommelseslækager. Brug det udelukkende i et isoleret testmiljø, og kontroller på forhånd, om det er tilgængeligt i den pågældende kerne og konfigureret korrekt. Den aktuelle dokumentation garanterer ikke, at det er tilgængeligt for alle ældre eller distributionsspecifikke kerner.

Også med dette diagnosemodul kan der ikke garanteres en øjeblikkelig melding eller et resultat ved den første scanning. Notér tidspunktet for testen og scanningsrækkefølgen, og gentag undersøgelsen på en kontrolleret måde. Hvis udskriften i første omgang forbliver tom, skal du kontrollere forudsætningerne og forløbet, i stedet for udelukkende at konkludere, at diagnosemiljøet fungerer eller er defekt.

Undersøg årsagen i stedet for at skjule meddelelsen

I tilfælde af mistanke skal du starte med at se på det rapporterede objekts livscyklus: Hvilken funktion reserverer det, hvem overtager derefter ansvaret, og hvornår skal det frigives? Allokerings-stacktrace fører dig til oprindelsen af reservationen. Om der er en fejl dér eller et senere sted, kan først vurderes ud fra kodestien.

Tjek især Ejerskab ved overførsler mellem funktioner og moduler. Når en reference videregives, skal det være klart, hvilken side der beholder den, og hvilken side der udfører frigivelsen. Sammenlign desuden den normale afviklingsvej med afbrydelses- og fejlveje, f.eks. hvis en initialisering kun gennemføres delvist.

Der kan også opstå en fejlmeddelelse, selvom der findes en gyldig reference, som kmemleak ikke genkender. Inden du undertrykker den, skal du derfor kontrollere, hvor og i hvilken form pegeren gemmes. Dokumenter, hvorfor objektet forbliver tilgængeligt i løbet af sin forventede levetid, og hvordan det til sidst frigives.

I godkendte særlige tilfælde står udviklere Annotationer til rådighed: kmemleak_not_leak markerer et kendt objekt som ikke værende en lækage, men lader det fortsat blive scannet for referencer. kmemleak_ignore udelukker objektet både fra meddelelsen og fra scanningen. Dermed kan referencer, der er indeholdt i det, mangle i analysen.

Kontroller API’ets tilgængelighed og semantik i den kernel, der rent faktisk anvendes; den aktuelle API-dokumentation er ikke automatisk en garanti for alle ældre builds. En annotation løser hverken en manglende godkendelse eller et fejlagtigt ejerskifte. Brug den derfor ikke alene for at få en forstyrrende udskrift til at forsvinde.

Fejlfinding og sikker drift

Mangler filen? /sys/kernel/debug/kmemleak, skal du først kontrollere den kernel-build, der rent faktisk er startet, og dens konfiguration. CONFIG_DEBUG_KMEMLEAK skal være til stede; distributionsversionsnummeret alene er ikke tilstrækkeligt. Notér build og konfiguration, så senere sammenligninger kan foregå på samme grundlag.

Kontroller derudover Aktivering under kørsel og integrationen af debugfs. Ved CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF kan boot-parameteren kmemleak=on kan være nødvendigt. En manglende fil skelner ikke selv mellem disse mulige årsager; ændringer i opstartsprocessen eller montering af debugfs hører hjemme i en godkendt testkonfiguration.

Hvis udskriften forbliver tom efter en test, skal du kontrollere, om den undersøgte proces faktisk blev udført, og om der var tilstrækkelig tid mellem processen og scanningen. Gentag testen under dokumenterede betingelser, og sammenlign med det gemte udgangsresultat. Selv da har en tom rapport sine begrænsninger: Ikke alle allokeringer og ikke alle relevante referencer registreres af kmemleak.

Sikr eksisterende fund mod ændringer i diagnosestatus. Udskriften kan indeholde interne adresser og andre følsomme oplysninger; behandl dem i overensstemmelse med adgangs- og offentliggørelsesreglerne i dit miljø. Udfør helst trin, der ændrer status, på et isoleret, godkendt testsystem, og tag højde for den ekstra diagnostiske indsats uden at antage en ubegrundet procentværdi.

Et stort lagerbehov eller Hukommelsesbelastning er et selvstændigt driftsproblem og i sig selv ikke et tegn på en kernel-lækage. Artiklen om hjælper med at vurdere ventetider og hukommelsesmangel Hukommelsespres i Linux-kernen. Kombiner sådanne driftsobservationer med en målrettet gennemgang af koder og fejlmeldinger, i stedet for straks at drage konklusioner om årsagen ud fra en RAM-kurve.

Vælg det rigtige diagnoseværktøj

Vælg værktøjet ud fra den formodede Fejlklasse, ikke alene ud fra det generelle symptom på stigende hukommelsesforbrug. kmemleak søger efter kernelobjekter, der muligvis er forladte, men stadig understøttes. Til ugyldige adgangsforespørgsler eller hukommelsesproblemer i en brugerproces er det hensigtsmæssigt at anvende en anden form for instrumentering; værktøjerne besvarer forskellige spørgsmål.

En mistanke om en mistet kernel-reference tyder i første omgang på kmemleak. Hvis et fejlbillede derimod viser en adgang uden for et objekt eller til allerede frigivet hukommelse, er KASAN velegnet til at undersøge denne type fejl. KFENCE sporer ligeledes bestemte hukommelsesfejl, men anvender en anden instrumenteringsmetode; tilgængelighed og egnethed afhænger af den konkrete kerne og testmiljøet.

Hvis der er mistanke om en proces i brugerrummet, skal du undersøge dens hukommelse med et værktøj, der er beregnet til dette formål, såsom Valgrind Memcheck. En kmemleak-rapport om kerneobjekter er ikke en erstatning for en analyse af en applikations heap. Omvendt forklarer en henvisning fra en brugerproces ikke automatisk, om et kernemodul mister hukommelse.

Vælg en til det videre arbejde reproducerbar test og dokumenter kernel-build, konfiguration og forløb. Undersøg den rapporterede objektlivscyklus i koden, ret en påvist årsag, og gentag det samme forløb under så ensartede betingelser som muligt. Sammenlign resultaterne igen; det faktum, at der ikke vises en fejlmeddelelse, er i sig selv ikke bevis på, at programmet er fuldstændig fejlfrit.