Identifiera och undersöka minnesläckor i kärnan med kmemleak

Vad kmemleak upptäcker i kärnan

Kmemleak stöder felsökning av Linux-kärnan genom att söka efter eventuellt övergivna minnesobjekt. För detta ändamål spårar programmet stödda allokeringar och kontrollerar om det går att upptäcka referenser till dessa objekt i de skannade minnesområdena. Ett objekt som inte identifieras som nåbart visas som ett möjligt minnesläckage, inte som ett slutgiltigt bevisat fel.

Tänk dig att en kärnmodul reserverar ett objekt och sedan förlorar den sista referensen till det utan att frigöra minnet. Om kmemleak vid sin Referenssökning Om det inte längre finns någon hänvisning till objektet kan det rapportera detta som misstänkt. Rapporten ger en utgångspunkt för att undersöka allokeringen och den avsedda livscykeln i koden.

Metoden liknar en garbage collectors sökning efter nåbarhet, men utför inte dess rensning: Kmemleak frigör inte rapporterade objekt och reparerar inte koden. Huruvida ett objekt faktiskt är förlorat måste avgöras utifrån dess användning, ägarförhållanden och den avsedda frigivningen.

Ett kernel-läckage berör minne som hanteras av kärnkoden eller en modul. Ett läckage i en PHP-tjänst eller en annan process i användarutrymmet utgör en annan typ av fel; kmemleak undersöker inte dess heap. För den bredare Upptäckt av minnesläckor i webbhotellsverksamheten Därför kan även processdata och andra diagnostikverktyg komma i fråga.

En ökad RAM-användning i sig är inte ett bevis på vare sig Minnesläcka eller var den finns. Även förändringar i arbetsomfånget eller data som sparas under längre tid kan påverka behovet. En lämplig utgångspunkt är därför en tidsmässigt och funktionellt avgränsad process, där en misstänkt kärnproblem kan undersökas på ett målinriktat sätt.

Varför anmälningar förblir misstänkta fall

Sökningen efter pekarvärden kan inte identifiera alla betydelser som ett program tilldelar en referens. Om en giltig referens ligger utanför de genomsökta områdena eller är lagrad på ett sätt som gör att kmemleak inte kan identifiera den, kan ett objekt som fortfarande behövs framstå som övergivet. Detta är en möjlig Falskt larm: Anmälan i sig bevisar inte att godkännandet saknas.

Det motsatta är också möjligt. Ett talvärde kan av en slump se ut som en pekare till ett objekt, även om koden inte använder det som en referens. Kmemleak kan då klassificera objektet som nåbart och förbise ett faktiskt läckage. En tom utskrift är därför inget bevis på att den granskade koden är felfri.

Därtill kommer omfattningen av de allokeringar som hanteras: direkta sidallokeringar och ioremap spåras inte enligt kärndokumentationen. Den som misstänker en minnesökning inom dessa områden kan inte dra slutsatsen att orsaken i fråga är utesluten enbart utifrån en oansenlig kmemleak-rapport. För detta krävs en annan typ av undersökning.

Die Tillgänglighet Det är alltså en teknisk heuristik och ingen fullständig semantisk analys av programmet. Den ger inget tillförlitligt svar på om en upptäckt referens används på ett meningsfullt sätt eller om en förbisedd referens faktiskt saknas. Ett enskilt fynd utgör en kontrolluppgift; avsaknaden av fynd begränsar endast slutsatsen av den aktuella genomsökningen.

För utvärderingen är det värt att återskapa misstanken under kontrollerade förhållanden och därefter granska den tillhörande kodvägen. Det är särskilt viktigt att klargöra vem som äger objektet och när det bör frigöras. Endast denna undersökning kan ge en rimlig förklaring till resultatet.

Kontrollera testmiljön och förutsättningarna

Den versionsspecifika dokumentationen för Linux 6.6 fungerar här som en teknisk utgångspunkt. Om kmemleak faktiskt är tillgängligt på ditt system beror dock på vilken kärnversion som används och dess konfiguration, inte enbart på versionsnumret. Kontrollera därför vilken distributionskärna som faktiskt är installerad och notera versionen och konfigurationen för senare utvärdering.

En förutsättning är att följande kärnalternativ är inkompilerat CONFIG_DEBUG_KMEMLEAK. Från detta skiljer sig Aktivering under körning: Är kärnan med CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF konfigurerad kan startparametern kmemleak=on kan behövas. Planera uttryckligen in ändringar i startprocessen för den godkända testkonfigurationen.

För att få åtkomst till diagnosgränssnittet måste dessutom debugfs vara tillgängliga och integrerade på rätt sätt. Kärnkonfiguration, aktivering och åtkomst till filsystemet är olika kontrollpunkter: Att ett gränssnitt saknas är i sig inte tillräckligt för att avgöra vilken av dessa som är orsaken. Åtkomst kan kräva särskilda behörigheter.

Använd om möjligt en isolerad virtuell maskin eller ett dedikerat testsystem och se till att få godkännande för ändringar i förväg. Kmemleak medför extra arbetsinsats vid allokeringar och frigöranden; effekten beror på miljön och belastningen. Utan lämpliga mätningar går det inte att ange någon allmängiltig prestandaförlust för detta.

Förutom kärnan ska du även dokumentera den modul som undersöks, det planerade förloppet och tidpunkten för utmatningen. Diagnosrapporter kan innehålla interna adresser och annan känslig information. Förvara dem på ett säkert sätt med begränsad åtkomst och kontrollera, innan du vidarebefordrar dem, vilka uppgifter som faktiskt behövs för felanalysen.

Gränssnitt och diagnoskommandon

Börja på det godkända testsystemet med läsbehörighet till /sys/kernel/debug/kmemleak. Filen visar aktuella rapporterade misstänkta fall. Åtkomst kan kräva särskilda behörigheter; ett tomt utdata beskriver endast det synliga diagnostiska tillståndet och bevisar inte att kärnan är fri från minnesläckor.

Kör följande kommando i ett skal med tillräckliga läsbehörigheter. Det påverkar inte diagnostikstatusen och lämpar sig även för att spara en första utvärdering innan ytterligare åtgärder vidtas.

cat /sys/kernel/debug/kmemleak

Om filen saknas finns det tre möjliga orsaker: Kärnan kan ha installerats utan CONFIG_DEBUG_KMEMLEAK byggd, kmemleak är inte aktiverat vid körning eller så är debugfs inte monterat på den förväntade platsen. Den saknade filen i sig avgör inte vilken av dessa orsaker som gäller. Kontrollera därför byggkonfigurationen, startkonfigurationen och monteringen var för sig.

I tabellen görs en medveten åtskillnad mellan läsning och Skrivbehörigheter: En skanning och rensning av den synliga listan påverkar diagnosstatusen. Även det eventuellt nödvändiga monterandet av debugfs påverkar systemet. Utför sådana åtgärder endast efter godkännande och med de behörigheter som krävs för detta; omdirigeringen vid skrivkommandon kräver också tillräckliga behörigheter.

Att på ett reproducerbart sätt avgränsa misstänkta fall

Se först till att du sparar en fullständig utskrift av gränssnittet tillsammans med tidpunkt, kärnbyggnad och testkonfiguration. Redan befintliga meddelanden ingår i Utgångsundersökning och får inte utan vidare tillskrivas följande test. Förvara utskriften på ett säkert ställe, eftersom den kan innehålla interna adresser och annan diagnostisk information.

På ett godkänt testsystem kan du sedan ta bort de meddelanden som för närvarande visas från listan över misstänkta fall med följande shell-kommando. Shellen behöver skrivrättigheter till gränssnittet. Kommandot frigör inga minnesblock och åtgärdar inte orsaken; utan en säkerhetskopia i förväg kan viktiga uppgifter gå förlorade.

echo clear > /sys/kernel/debug/kmemleak

Inled därefter en så avgränsad och dokumenterad process som möjligt, till exempel initialisering och kontrollerad rensning av en modul som ska undersökas. Dokumentera vilka steg som har utförts och när de slutfördes. På så sätt kan en senare upptäckt jämföras mer konkret med arbetsflödet, utan att den tidsmässiga närheten i sig bevisar ett orsakssamband.

När tiden har gått ut, starta en skanning i en behörig shell och läs sedan in gränssnittet på nytt. Båda kommandona förutsätter att kmemleak är aktivt och att debugfs-gränssnittet är tillgängligt.

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

Upprepa proceduren på ett kontrollerat sätt och ge den tillräckligt med tid. En skanning behöver inte omedelbart ge ett reproducerbart resultat. För en regression, jämför samma test före och efter kodändringen med så likartad kärnkonfiguration och belastning som möjligt; dokumentera kvarstående skillnader. En ny misstanke stöder en hypotes, men ersätter inte granskningen av objektets livscykel.

Modultest och utvärdering av resultat

Vid ett modultest kan du till exempel köra en initialiseringsväg och därefter låta den avsedda upprensningsvägen köras igenom. Om en ny post dyker upp därefter ska du först notera objektets storlek, ålder och processkontext samt de tillhörande teststegen. Dessa uppgifter hjälper till att klassificera resultaten; de visar i sig inte om objektet faktiskt borde ha frigjorts.

Der Allokeringsstackspår leder till den plats där minnet begärdes. Därifrån kan du spåra i koden vem som tar över objektet och vilken väg det ska frigöras igen. Spårningen behöver inte innehålla den plats där frigörandet uteblev: Allokeringen och den uteblivna upprensningen kan ligga i olika funktioner.

Tänk också på att Allokeringsordning: Dokumentationen beskriver utdata i denna ordning. Ett tidigare övergivet objekt kan leda till ytterligare meddelanden. Kontrollera därför om flera poster hör till samma objektgrupp eller felväg innan du räknar dem som fristående fel.

För en valfri funktionskontroll beskrivs modulen i den aktuella kärndokumentationen kmemleak-test, som avsiktligt skapar minnesläckor. Använd det endast i en isolerad testmiljö och kontrollera först om det finns tillgängligt i den aktuella kärnan och är korrekt konfigurerat. Den föränderliga aktuella dokumentationen garanterar inte att det är tillgängligt för alla äldre eller distributionsspecifika kärnor.

Även med denna diagnosmodul kan man inte garantera att ett meddelande visas omedelbart eller att en träff uppnås vid den första skanningen. Notera tidpunkten för testet och skanningssekvensen och upprepa undersökningen på ett kontrollerat sätt. Om utdata först förblir tom, kontrollera förutsättningarna och förfarandet istället för att enbart dra slutsatsen att diagnosmiljön fungerar eller är defekt.

Kontrollera orsaken istället för att dölja meddelandet

Vid ett misstänkt fall bör du börja med det rapporterade objektets livscykel: Vilken funktion reserverar det, vem tar sedan över ansvaret och när ska det frigöras? Allokeringsstackspåret leder dig till källan till reserveringen. Om felet ligger där eller längre fram kan endast bedömas utifrån kodvägen.

Kontrollera särskilt Ägarförhållanden vid överlämningar mellan funktioner och moduler. Om en referens vidarebefordras måste det stå klart vilken sida som behåller den och vilken sida som utför frigörandet. Jämför dessutom den normala avslutningsvägen med avbrotts- och felvägar, till exempel när en initialisering endast slutförs delvis.

Ett felmeddelande kan uppstå även om det finns en giltig referens som kmemleak inte känner igen. Innan du undertrycker det bör du därför kontrollera var och i vilken form pekaren lagras. Dokumentera varför objektet förblir åtkomligt under sin avsedda livslängd och på vilket sätt det slutligen frigörs.

För granskade specialfall står utvecklare Kommentarer tillgängligt: kmemleak_not_leak markerar ett känt objekt som inte utgör en läcka, men låter systemet fortsätta att söka efter referenser till det. kmemleak_ignore utesluter objektet både från rapporten och från skanningen. Detta kan leda till att referenser som finns i objektet saknas i analysen.

Kontrollera API:ets tillgänglighet och semantik i den kärna som faktiskt används; den aktuella API-dokumentationen innebär inte automatiskt att den gäller för alla äldre versioner. En anteckning åtgärdar varken en utebliven godkännande eller ett felaktigt ägarbyte. Använd den därför inte enbart för att få bort ett störande utdata.

Felsökning och säker drift

Saknas filen? /sys/kernel/debug/kmemleak, kontrollera först vilken kernel-build som faktiskt har startats och dess konfiguration. CONFIG_DEBUG_KMEMLEAK måste finnas; enbart versionsnumret för en distribution räcker inte för detta. Dokumentera byggprocessen och konfigurationen så att senare jämförelser kan göras utifrån samma underlag.

Kontrollera dessutom Aktivering under körning och integreringen av debugfs. Vid CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF kan startparametern kmemleak=on kan krävas. En saknad fil gör det inte möjligt att själv skilja mellan dessa möjliga orsaker; ändringar av startprocessen eller att montera debugfs hör hemma i en godkänd testkonfiguration.

Om utdata förblir tom efter ett test, kontrollera om den undersökta processen verkligen har körts och om det har gått tillräckligt med tid mellan processen och skanningen. Upprepa testet under dokumenterade förhållanden och jämför med det sparade utgångsresultatet. Även då har en tom rapport sina begränsningar: inte varje allokering och inte varje relevant referens registreras av kmemleak.

Säkra befintliga resultat innan du gör ändringar i diagnosstatusen. Utdata kan innehålla interna adresser och annan känslig information; hantera den i enlighet med åtkomst- och publiceringsreglerna i din miljö. Utför åtgärder som förändrar tillståndet helst på ett isolerat, godkänt testsystem och ta hänsyn till den extra diagnostiska arbetsinsatsen utan att anta ett ogrundat procentvärde för detta.

Ett stort lagringsbehov eller Minnebelastning är ett fristående driftsproblem och utgör i sig inte något bevis på en kärnläcka. För att kunna bedöma väntetider och minnesbrist är artikeln om Minnesbelastning i Linux-kärnan. Kombinera sådana driftsobservationer med en målinriktad granskning av koden och felfindningarna, istället för att direkt dra slutsatser om orsaken utifrån en RAM-kurva.

Välja rätt diagnostikverktyg

Välj verktyget utifrån den förmodade Felkategori, inte enbart utifrån det allmänna symptomet med ökande minnesanvändning. kmemleak söker efter eventuellt övergivna, stödda kärnobjekt. För ogiltiga åtkomstförsök eller minnesproblem i en användarprocess är det lämpligt att använda en annan typ av instrumentering; verktygen ger svar på olika frågor.

Om man misstänker en förlorad kärnreferens tyder det i första hand på kmemleak. Om felbilden däremot visar på åtkomst utanför ett objekt eller till redan frigjort minne, är KASAN lämpligt för att undersöka denna typ av fel. KFENCE spårar också vissa minnesfel, men använder en annan instrumenteringsmetod; tillgänglighet och lämplighet beror på den specifika kärnan och testmiljön.

Om misstanken riktas mot en process i användarutrymmet, undersök dess minne med ett verktyg avsett för detta ändamål, till exempel Valgrind Memcheck. En kmemleak-rapport om kärnobjekt ersätter inte en analys av en applikations heap. Omvänt innebär en indikation från en användarprocess inte automatiskt att en kärnmodul förlorar minne.

Välj en för det fortsatta arbetet reproducerbart test och dokumentera kärnbyggandet, konfigurationen och förloppet. Undersök den rapporterade objektets livscykel i koden, åtgärda en konstaterad orsak och upprepa samma förlopp under så likartade förhållanden som möjligt. Jämför resultaten på nytt; att ett fel inte uppstår vid ett tillfälle är i sig inte ett bevis på att systemet är helt felfritt.