Individuare e analizzare le perdite di memoria del kernel con kmemleak

Cosa rileva kmemleak nel kernel

Kmemleak Supporta il debug del kernel Linux cercando oggetti di memoria potenzialmente orfani. A tal fine, tiene traccia delle allocazioni supportate e verifica se nelle aree di memoria analizzate siano presenti riferimenti a tali oggetti. Un oggetto non riconosciuto come raggiungibile viene segnalato come potenziale perdita di memoria, non come errore definitivamente accertato.

Immagina che un modulo del kernel riservi un oggetto e poi ne perda l'ultimo riferimento senza liberare la memoria. Se kmemleak, durante la sua Ricerca per riferimento Se non trova più alcun riferimento all'oggetto, può segnalarlo come sospetto. La segnalazione fornisce un punto di partenza per esaminare l'allocazione e il ciclo di vita previsto nel codice.

Il processo è simile alla ricerca di raggiungibilità di un garbage collector, ma non ne esegue la pulizia: Kmemleak non libera gli oggetti segnalati e non corregge il codice. Per stabilire se un oggetto sia effettivamente andato perso, occorre valutare il suo utilizzo, la sua proprietà e la procedura di liberazione prevista.

Una perdita nel kernel riguarda la memoria gestita dal codice del kernel o da un modulo. Una perdita in un servizio PHP o in un altro processo dello spazio utente rientra in una categoria diversa di errori; kmemleak non analizza il relativo heap. Per una visione più ampia Rilevamento delle perdite di memoria nell'ambito dei servizi di hosting Si possono quindi prendere in considerazione anche dati di processo e altri strumenti diagnostici.

L'aumento dell'utilizzo della RAM di per sé non dimostra né un Perdita di memoria né il luogo in cui si verifica. Anche una variazione dell’ambito di lavoro o una conservazione più prolungata dei dati possono influire sulle esigenze. Un punto di partenza sensato è quindi un processo definibile in termini temporali e funzionali, che consenta di indagare in modo mirato su un sospetto relativo al kernel.

Perché le segnalazioni rimangono casi sospetti

La ricerca dei valori dei puntatori non è in grado di riconoscere tutti i significati che un programma attribuisce a un riferimento. Se un riferimento valido si trova al di fuori delle aree analizzate o è memorizzato in modo tale che kmemleak non lo riconosca, un oggetto ancora necessario potrebbe apparire come orfano. Questo è un possibile Falso allarme: La segnalazione di per sé non dimostra che manchi l'autorizzazione.

È possibile anche il contrario. Un valore numerico può casualmente assomigliare a un puntatore a un oggetto, anche se il codice non lo utilizza come riferimento. Kmemleak potrebbe quindi classificare l'oggetto come raggiungibile e trascurare una vera e propria perdita di memoria. Un risultato vuoto non è quindi una prova che il codice analizzato sia privo di errori.

A ciò si aggiunge l'entità delle allocazioni gestite: allocazioni dirette di pagine e ioremap secondo la documentazione del kernel, non vengono monitorati. Chi sospetta un aumento dell'utilizzo della memoria in queste aree non può dedurre da un rapporto kmemleak non significativo che la causa in questione sia da escludere. A tal fine è necessaria un'analisi condotta in modo diverso.

Il sito Accessibilità Si tratta quindi di un’euristica tecnica e non di un’analisi semantica completa del programma. Non fornisce una risposta affidabile sul fatto che un riferimento individuato venga utilizzato in modo corretto o che un riferimento trascurato sia effettivamente mancante. Un singolo risultato costituisce un’operazione di verifica; l’assenza di risultati limita semplicemente la validità delle conclusioni della rispettiva scansione.

Ai fini della valutazione, è opportuno ricreare il sospetto in condizioni controllate e quindi esaminare il percorso di codice corrispondente. In particolare, occorre chiarire chi sia il proprietario dell’oggetto e quando dovrebbe essere rilasciato. Solo questa analisi può fornire una spiegazione plausibile del risultato.

Verificare l'ambiente di test e i prerequisiti

La documentazione relativa alla versione Linux 6.6 funge qui da base tecnica di riferimento. Tuttavia, la disponibilità effettiva di kmemleak sul tuo sistema dipende dalla build del kernel utilizzata e dalla sua configurazione, non solo dal numero di versione. Verifica quindi il kernel della distribuzione effettivamente installato e prendi nota della build e della configurazione per una successiva analisi.

Un requisito è l'opzione del kernel compilata CONFIG_DEBUG_KMEMLEAK. Da ciò va distinta la Attivazione a tempo: Il kernel è compilato con CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF una volta configurato, il parametro di avvio kmemleak=on potrebbe essere necessario. Prevedere espressamente le modifiche alla procedura di avvio per la configurazione di test approvata.

Per accedere all'interfaccia diagnostica è inoltre necessario debugfs devono essere disponibili e integrati in modo adeguato. La configurazione del kernel, l’attivazione e l’accesso al filesystem sono diversi punti di controllo: la sola assenza di un’interfaccia non è ancora indicativa di quale di questi sia la causa. Per l’accesso potrebbero essere necessari diritti privilegiati.

Se possibile, utilizza una macchina virtuale isolata o un sistema di test dedicato e ottieni l'autorizzazione per le modifiche in anticipo. Kmemleak comporta un carico aggiuntivo in termini di allocazioni e liberazioni; l'impatto dipende dall'ambiente e dal carico di lavoro. Senza misurazioni adeguate, non è possibile indicare una penalizzazione generale in termini di prestazioni.

Oltre al kernel, documenta anche il modulo oggetto di analisi, la sequenza prevista e il momento in cui si è verificato l'errore. I rapporti diagnostici possono contenere indirizzi interni e altre informazioni sensibili. Conservali in un luogo con accesso limitato e, prima di divulgarli, verifica quali dati siano effettivamente necessari per l'analisi dell'errore.

Interfaccia e comandi di diagnostica

Sul sistema di test autorizzato, inizia con un accesso in lettura a /sys/kernel/debug/kmemleak. Il file riporta i casi sospetti attualmente segnalati. L'accesso potrebbe richiedere diritti privilegiati; un output vuoto descrive solo lo stato diagnostico visibile e non dimostra che il kernel sia privo di perdite di memoria.

Esegui il seguente comando in una shell con diritti di lettura sufficienti. Il comando non modifica lo stato diagnostico ed è utile anche per salvare una prima valutazione prima di procedere con ulteriori passaggi.

cat /sys/kernel/debug/kmemleak

Se il file manca, si possono distinguere tre possibili cause: il kernel potrebbe essere stato installato senza CONFIG_DEBUG_KMEMLEAK Compilato: kmemleak non è attivato in fase di esecuzione oppure debugfs non è montato nella posizione prevista. La sola assenza del file non permette di stabilire quale delle due ipotesi sia corretta. Verifica quindi separatamente la configurazione di compilazione, la configurazione di avvio e il montaggio.

La tabella distingue volutamente tra lettura e Accessi in scrittura: Una scansione e la pulizia dell'elenco visibile modificano lo stato diagnostico. Anche il montaggio di debugfs, qualora fosse necessario, modifica il sistema. Esegui tali operazioni solo previa autorizzazione e con i diritti necessari; anche il reindirizzamento dei comandi di scrittura richiede diritti sufficienti.

Individuare i casi sospetti in modo riproducibile

Per prima cosa, salva l'output completo dell'interfaccia insieme alla data e all'ora, alla build del kernel e alla configurazione di test. I messaggi già presenti fanno parte del Esami iniziali e non devono essere attribuiti al test seguente senza un confronto. Conserva la stampa in un luogo sicuro, poiché potrebbe contenere indirizzi interni e altre informazioni diagnostiche.

Su un sistema di test autorizzato, puoi quindi rimuovere dalla lista dei sospetti i messaggi attualmente visibili utilizzando il seguente comando della shell. La shell richiede i diritti di scrittura sull'interfaccia. Il comando non libera alcun blocco di memoria e non risolve la causa del problema; senza un previo backup, potrebbero andare perse informazioni importanti.

echo clear > /sys/kernel/debug/kmemleak

Avvia quindi una procedura il più possibile circoscritta e documentata, ad esempio l’inizializzazione e la pulizia controllata di un modulo da esaminare. Annota quali passaggi sono stati eseguiti e quando sono stati completati. In questo modo, un ritrovamento successivo potrà essere confrontato in modo più concreto con la procedura, senza che la sola vicinanza temporale provi di per sé un nesso causale.

Al termine, avvia una scansione in una shell con i permessi adeguati e poi rileggi l'interfaccia. Entrambi i comandi presuppongono che kmemleak sia attivo e che l'interfaccia debugfs sia disponibile.

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

Ripeti la procedura in modo controllato e concedile tempo sufficiente. Una scansione non deve necessariamente fornire immediatamente un risultato riproducibile. Per verificare la regressione, confronta lo stesso test prima e dopo la modifica del codice, mantenendo il più possibile invariate la configurazione del kernel e il carico; documenta le differenze residue. Un nuovo sospetto avvalora un’ipotesi, ma non sostituisce la verifica del ciclo di vita dell’oggetto.

Test del modulo e valutazione dei risultati

Durante un test del modulo, ad esempio, puoi eseguire un percorso di inizializzazione e successivamente far eseguire il percorso di pulizia previsto. Se in seguito compare una nuova voce, annota innanzitutto le dimensioni dell’oggetto, la sua età e il contesto di processo, nonché le relative fasi di test. Queste informazioni aiutano ad attribuire i risultati; di per sé, tuttavia, non indicano ancora se l’oggetto avrebbe effettivamente dovuto essere rilasciato.

Il sito Traccia dello stack di allocazione porta al punto in cui è stata richiesta l'allocazione di memoria. Da lì puoi seguire nel codice chi prende in carico l'oggetto e quale percorso dovrebbe seguire per liberarlo. La traccia non deve necessariamente includere il punto in cui non è avvenuta la liberazione: l'allocazione e la mancata liberazione possono avvenire in funzioni diverse.

Tieni conto anche della Ordine di allocazione: La documentazione descrive l'output in questo ordine. Un oggetto abbandonato in precedenza può comportare ulteriori messaggi. Verifica quindi se più voci appartengono allo stesso insieme di oggetti o allo stesso percorso di errore prima di considerarle come difetti indipendenti.

Per un test funzionale facoltativo, la documentazione attuale del kernel descrive il modulo kmemleak-test, che genera intenzionalmente perdite di memoria. Utilizzalo esclusivamente in un ambiente di test isolato e verifica preventivamente se è disponibile nel kernel specifico e se è configurato correttamente. La documentazione attuale, soggetta a modifiche, non garantisce la sua disponibilità per tutti i kernel meno recenti o specifici di una determinata distribuzione.

Anche con questo modulo diagnostico non è garantita una segnalazione immediata o un risultato positivo alla prima scansione. Annota l'ora del test e la sequenza di scansione e ripeti l'esame in modo controllato. Se il risultato rimane inizialmente vuoto, verifica i prerequisiti e la procedura, invece di dedurre automaticamente che l'ambiente diagnostico sia funzionante o difettoso.

Verificare la causa invece di nascondere il messaggio

In caso di sospetto, inizia dall’analizzare il ciclo di vita dell’oggetto segnalato: quale funzione riserva, chi se ne assume successivamente la responsabilità e quando dovrebbe essere rilasciato? La traccia dello stack di allocazione ti conduce all’origine della prenotazione. Solo analizzando il percorso del codice è possibile stabilire se l’errore si trovi in quel punto o in uno successivo.

Controlla in particolare il Struttura azionaria nei passaggi tra funzioni e moduli. Quando viene passato un riferimento, deve essere chiaro quale parte lo mantiene e quale parte esegue il rilascio. Confronta inoltre il percorso di pulizia regolare con i percorsi di interruzione e di errore, ad esempio quando un’inizializzazione viene completata solo parzialmente.

È possibile che venga generato un messaggio di errore anche se esiste un riferimento valido che kmemleak non riconosce. Prima di sopprimerlo, verifica quindi dove e in che forma viene memorizzato il puntatore. Documenta il motivo per cui l'oggetto rimane accessibile durante il suo ciclo di vita previsto e in che modo viene infine liberato.

Per i casi particolari verificati, gli sviluppatori hanno a disposizione Annotazioni a disposizione: kmemleak_not_leak contrassegna un oggetto noto come "non leak", ma continua a eseguire la scansione alla ricerca di riferimenti. kmemleak_ignore esclude l'oggetto sia dalla segnalazione che dalla scansione. Di conseguenza, i riferimenti in esso contenuti potrebbero non essere presenti nell'analisi.

Verifica la disponibilità e la semantica dell’API nel kernel effettivamente in uso; la documentazione attuale dell’API non costituisce automaticamente una garanzia per ogni build precedente. Un’annotazione non risolve né una mancanza di autorizzazione né un cambio di proprietà errato. Non utilizzarla quindi solo per far sparire un messaggio di errore fastidioso.

Risoluzione dei problemi e funzionamento sicuro

Il file non è presente /sys/kernel/debug/kmemleak, verifica innanzitutto la build del kernel effettivamente avviata e la relativa configurazione. CONFIG_DEBUG_KMEMLEAK deve essere presente; il numero di versione di una distribuzione da solo non è sufficiente a tal fine. Registra la build e la configurazione, in modo che i confronti successivi avvengano sulla stessa base.

Controlla, a parte questo, il Attivazione a tempo e l'integrazione di debugfs. In CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF è possibile impostare il parametro di avvio kmemleak=on potrebbe essere necessario. Un file mancante non distingue di per sé queste possibili cause; le modifiche alla procedura di avvio o il montaggio di debugfs devono essere effettuate in una configurazione di test approvata.

Se, al termine di un test, l'output risulta vuoto, verifica se il flusso esaminato sia stato effettivamente eseguito e se tra l'esecuzione del flusso e la scansione sia trascorso un intervallo di tempo sufficiente. Ripetere il test in condizioni documentate e confrontare i risultati con quelli iniziali salvati. Anche in questo caso, però, un rapporto vuoto ha un valore limitato: kmemleak non rileva tutte le allocazioni né tutti i riferimenti rilevanti.

Proteggi i risultati esistenti da eventuali modifiche allo stato diagnostico. L'output può contenere indirizzi interni e altre informazioni sensibili; trattale in conformità con le regole di accesso e pubblicazione del tuo ambiente. Esegui le operazioni che modificano lo stato preferibilmente su un sistema di test isolato e autorizzato, tenendo conto del carico diagnostico aggiuntivo senza attribuirgli una percentuale non specificata.

Un elevato fabbisogno di memoria oppure Pressione sulla memoria è un problema operativo a sé stante e, di per sé, non costituisce una prova di una falla nel kernel. Per valutare i tempi di attesa e la carenza di memoria, è utile l'articolo su Pressione di memoria nel kernel Linux. Combina tali osservazioni operative con un’analisi mirata dei codici e dei referti, invece di trarre conclusioni immediate sulla causa partendo da una curva RAM.

Scegliere lo strumento diagnostico più adatto

Scegli l'attrezzo in base alla presunta Classe di errore, non solo in base al sintomo generico di un aumento dell'utilizzo della memoria. kmemleak ricerca oggetti del kernel supportati che potrebbero essere orfani. Per gli accessi non validi o i problemi di memoria di un processo utente è opportuno ricorrere a un'altra strumentazione; gli strumenti rispondono a domande diverse.

Il sospetto di un riferimento al kernel perso fa inizialmente pensare a kmemleak. Se invece un errore indica un accesso al di fuori di un oggetto o a memoria già liberata, KASAN è lo strumento adatto per analizzare questa categoria. Anche KFENCE monitora determinati errori di memoria, ma adotta un approccio di strumentazione diverso; la disponibilità e l’idoneità dipendono dal kernel specifico e dall’ambiente di test.

Se si sospetta che il problema riguardi un processo dello spazio utente, esaminarne la memoria con uno strumento specifico come Valgrind Memcheck. Un rapporto kmemleak relativo agli oggetti del kernel non sostituisce l'analisi dell'heap di un'applicazione. Viceversa, un'indicazione proveniente da un processo dello spazio utente non spiega automaticamente se un modulo del kernel sta perdendo memoria.

Per proseguire il lavoro, scegli un test riproducibile e documenta la compilazione del kernel, la configurazione e il flusso di esecuzione. Esamina nel codice il ciclo di vita dell’oggetto segnalato, correggi la causa individuata e ripeti lo stesso flusso di esecuzione in condizioni il più possibile identiche. Confronta nuovamente i risultati; la sola assenza di un messaggio non dimostra ancora la completa assenza di errori.