Detectar y analizar fugas de memoria del núcleo con kmemleak

Lo que detecta kmemleak en el núcleo

Kmemleak Facilita la depuración del núcleo de Linux buscando objetos de memoria que puedan estar huérfanos. Para ello, realiza un seguimiento de las asignaciones compatibles y comprueba si se detectan referencias a dichos objetos en las áreas de memoria analizadas. Un objeto que no se detecta como accesible aparece como una posible fuga, no como un error demostrado de forma concluyente.

Imagina que un módulo del núcleo reserva un objeto y, a continuación, pierde la última referencia al mismo sin liberar la memoria. Si kmemleak, durante su Búsqueda de referencias Si ya no hay ninguna referencia al objeto, puede marcarlo como sospechoso. El aviso proporciona un punto de partida para examinar la asignación y el ciclo de vida previsto en el código.

El procedimiento es similar a la búsqueda de accesibilidad de un recolector de basura, pero no lleva a cabo su limpieza: Kmemleak no libera los objetos notificados ni repara el código. Para determinar si un objeto se ha perdido realmente, hay que analizar su uso, quién lo posee y el proceso de liberación previsto.

Una fuga del núcleo afecta a la memoria gestionada por el código del núcleo o por un módulo. Una fuga en un servicio PHP o en otro proceso del espacio de usuario constituye otro tipo de error; kmemleak no analiza su pila. Para un análisis más amplio Detección de fugas de memoria en el servicio de alojamiento web Por lo tanto, también se pueden tener en cuenta los datos de proceso y otras herramientas de diagnóstico.

El simple hecho de que el uso de la RAM aumente no demuestra por sí solo que haya un Fuga de memoria ni su ubicación. Un cambio en el alcance del trabajo o el almacenamiento prolongado de datos también pueden influir en las necesidades. Por lo tanto, un punto de partida adecuado es un proceso que se pueda delimitar en el tiempo y en cuanto a su funcionalidad, en el que se pueda investigar de forma específica una sospecha relacionada con el núcleo.

Por qué las notificaciones siguen siendo casos sospechosos

La búsqueda de valores de puntero no puede detectar todos los significados que un programa asigna a una referencia. Si una referencia válida se encuentra fuera de las áreas analizadas o está almacenada de tal forma que kmemleak no la detecta, un objeto que aún se necesita puede aparecer como huérfano. Este es un posible Falsa alarma: El simple hecho de que se haya notificado no demuestra por sí solo que falte la autorización.

También puede ocurrir lo contrario. Un valor numérico puede parecer, por casualidad, un puntero a un objeto, aunque el código no lo utilice como referencia. Kmemleak puede entonces clasificar el objeto como accesible y pasar por alto una fuga real. Por lo tanto, una salida vacía no es prueba de que el código analizado esté libre de errores.

A esto hay que añadir el alcance de las asignaciones que se gestionan: asignaciones directas de páginas y ioremap Según la documentación del núcleo, no se supervisan. Quien sospeche un aumento de memoria en estas áreas no puede dar por descartada la causa en cuestión basándose únicamente en un informe de kmemleak que no revele nada llamativo. Para ello es necesario realizar un análisis diferente.

El Accesibilidad Se trata, por tanto, de una heurística técnica y no de un análisis semántico completo del programa. No permite determinar de forma fiable si una referencia detectada se utiliza de forma adecuada o si una referencia que se ha pasado por alto realmente falta. Cada resultado detectado constituye una tarea de comprobación; la ausencia de resultados solo limita la validez de cada análisis.

Para la evaluación, conviene reproducir la sospecha en condiciones controladas y, a continuación, examinar la ruta de código correspondiente. En particular, hay que aclarar quién es el propietario del objeto y cuándo debería liberarse. Solo este análisis puede ofrecer una explicación plausible para el hallazgo.

Comprobar el entorno de prueba y los requisitos previos

La documentación con número de versión para Linux 6.6 sirve aquí como base técnica. Sin embargo, que kmemleak esté realmente disponible en tu sistema depende de la compilación del núcleo utilizada y de su configuración, y no solo del número de versión. Por lo tanto, comprueba el núcleo de la distribución que tengas instalado y anota la compilación y la configuración para su posterior análisis.

Un requisito previo es que la opción del núcleo esté compilada CONFIG_DEBUG_KMEMLEAK. Independientemente de ello, está la Activación en tiempo de ejecución: ¿Está el kernel con CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF una vez configurado, el parámetro de arranque kmemleak=on puede ser necesario. Planifica expresamente los cambios en el proceso de arranque para la configuración de prueba autorizada.

Para acceder a la interfaz de diagnóstico, además, es necesario debugfs estar disponible e integrada adecuadamente. La configuración del núcleo, la activación y el acceso al sistema de archivos son distintos puntos de comprobación: el hecho de que falte una interfaz por sí solo no indica cuál de ellos es la causa. Para el acceso pueden ser necesarios derechos privilegiados.

Si es posible, utiliza una máquina virtual aislada o un sistema de pruebas dedicado y solicita autorización previa para realizar cambios. Kmemleak supone un esfuerzo adicional en las asignaciones y liberaciones; el impacto depende del entorno y de la carga. Sin las mediciones adecuadas, no es posible indicar una merma de rendimiento generalizada.

Además del núcleo, documenta también el módulo analizado, el proceso previsto y el momento en que se produjo el error. Los informes de diagnóstico pueden contener direcciones internas y otra información sensible. Guárdalos en un lugar con acceso restringido y, antes de compartirlos, comprueba qué datos son realmente necesarios para el análisis del error.

Interfaz y comandos de diagnóstico

Empieza en el sistema de pruebas compartido con un acceso de lectura a /sys/kernel/debug/kmemleak. El archivo muestra los casos sospechosos notificados actualmente. Es posible que se requieran derechos de acceso privilegiados; una salida vacía solo describe el estado de diagnóstico visible y no demuestra que el núcleo esté libre de fugas de memoria.

Ejecuta el siguiente comando en un terminal con los permisos de lectura suficientes. No modifica el estado de diagnóstico y también resulta útil para guardar un primer informe antes de dar otros pasos.

cat /sys/kernel/debug/kmemleak

Si falta el archivo, hay tres posibles causas: es posible que el núcleo se haya instalado sin CONFIG_DEBUG_KMEMLEAK Compilado: kmemleak no está activado en tiempo de ejecución o debugfs no está montado en la ubicación esperada. La ausencia del archivo por sí sola no determina cuál de estas dos situaciones se da. Por lo tanto, comprueba por separado la configuración de compilación, la configuración de arranque y el montaje.

La tabla distingue deliberadamente entre «leer» y Accesos de escritura: Un escaneo y la limpieza de la lista visible modifican el estado de diagnóstico. El montaje de «debugfs», si fuera necesario, también modifica el sistema. Realiza estos pasos únicamente con autorización y los permisos necesarios para ello; el redireccionamiento de los comandos de escritura también requiere permisos suficientes.

Delimitar los casos sospechosos de forma reproducible

En primer lugar, guarda la salida completa de la interfaz junto con la hora, la compilación del kernel y la configuración de prueba. Los mensajes ya existentes forman parte de la Evaluación inicial y no deben atribuirse sin más a la prueba siguiente. Guarda la copia en un lugar seguro, ya que puede contener direcciones internas y otra información de diagnóstico.

En un sistema de pruebas habilitado, puedes eliminar posteriormente los mensajes que aparecen actualmente de la lista de sospechosos mediante el siguiente comando de shell. El shell necesita permisos de escritura en la interfaz. El comando no libera bloques de memoria ni soluciona la causa; sin una copia de seguridad previa, se pueden perder datos importantes.

echo clear > /sys/kernel/debug/kmemleak

A continuación, inicia un proceso lo más delimitado y documentado posible, como por ejemplo la inicialización y la limpieza controlada de un módulo que se vaya a examinar. Anota qué pasos se han llevado a cabo y cuándo se completaron. De este modo, si más adelante se detecta algún hallazgo, se podrá relacionar de forma más concreta con el proceso, sin que la mera proximidad temporal demuestre por sí sola una relación causal.

Una vez transcurrido el tiempo, inicia un escaneo en un shell con los permisos adecuados y, a continuación, vuelve a leer la interfaz. Ambos comandos requieren que kmemleak esté activo y que la interfaz debugfs esté disponible.

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

Repite el proceso de forma controlada y dedícale el tiempo suficiente. Un escaneo no tiene por qué arrojar inmediatamente un resultado reproducible. Para realizar una regresión, compara la misma prueba antes y después del cambio en el código, manteniendo, en la medida de lo posible, la misma configuración del núcleo y la misma carga; documenta las diferencias que persistan. Una nueva sospecha respalda una hipótesis, pero no sustituye al análisis del ciclo de vida del objeto.

Prueba del módulo y evaluación de los resultados

En una prueba de módulo, por ejemplo, puedes ejecutar una ruta de inicialización y, a continuación, recorrer la ruta de limpieza prevista. Si después aparece una nueva entrada, anota primero el tamaño del objeto, su antigüedad y el contexto del proceso, así como los pasos de prueba correspondientes. Estos datos ayudan a clasificar los resultados; por sí solos, aún no indican si el objeto realmente debería haberse liberado.

El Rastreo de pila de asignación te lleva al punto en el que se solicitó la memoria. Desde allí, puedes seguir en el código quién se hace cargo del objeto y qué ruta debe seguir para liberarlo. El rastreo no tiene por qué incluir el punto en el que no se ha producido la liberación: la asignación y la falta de liberación pueden encontrarse en funciones diferentes.

Ten en cuenta también la Orden de asignación: La documentación describe los mensajes en este orden. Un objeto abandonado anterior puede dar lugar a otros mensajes. Por lo tanto, comprueba si varias entradas pertenecen al mismo conjunto de objetos o a la misma ruta de error antes de contabilizarlas como defectos independientes.

Para realizar una prueba de funcionamiento opcional, la documentación actual del núcleo describe el módulo kmemleak-test, que genera fugas de memoria de forma intencionada. Úsalo exclusivamente en un entorno de prueba aislado y comprueba antes si está disponible en el núcleo concreto y si está configurado adecuadamente. La documentación actual, que está en constante evolución, no garantiza su disponibilidad para todos los núcleos antiguos o específicos de cada distribución.

Tampoco en este módulo de diagnóstico se garantiza que se genere un mensaje inmediato o que se obtenga un resultado positivo en el primer escaneo. Anota la hora de la prueba y la secuencia de escaneo, y repite el análisis de forma controlada. Si el resultado aparece vacío en un primer momento, comprueba los requisitos previos y el procedimiento, en lugar de deducir únicamente a partir de ello que el entorno de diagnóstico funciona correctamente o que está defectuoso.

Comprobar la causa en lugar de ocultar el mensaje

En caso de sospecha, empieza por el ciclo de vida del objeto notificado: ¿qué función reserva, quién asume la responsabilidad a continuación y cuándo debe liberarse? El seguimiento de la pila de asignación te lleva hasta el origen de la reserva. Solo se puede determinar si el error se encuentra ahí o en un punto posterior analizando la ruta del código.

Comprueba especialmente la Estructura accionarial en las transferencias entre funciones y módulos. Cuando se pasa una referencia, debe quedar claro qué parte la conserva y cuál lleva a cabo la liberación. Compara, además, la ruta de limpieza habitual con las rutas de interrupción y de error, por ejemplo, cuando una inicialización solo se completa parcialmente.

También puede aparecer un mensaje de error aunque exista una referencia válida que kmemleak no detecte. Por lo tanto, antes de ignorarlo, comprueba dónde y de qué forma se almacena el puntero. Documenta por qué el objeto sigue siendo accesible durante su vida útil prevista y de qué manera se libera finalmente.

Para los casos especiales que se hayan comprobado, los desarrolladores disponen de Anotaciones A tu disposición: kmemleak_not_leak marca un objeto conocido como «sin fuga», pero sigue analizando si tiene referencias. kmemleak_ignore Excluye el objeto tanto del informe como del análisis. Por ello, es posible que falten en el análisis las referencias que contiene.

Comprueba la disponibilidad y la semántica de la API en el kernel que se utilice realmente; la documentación actual de la API no garantiza automáticamente su compatibilidad con todas las versiones anteriores. Una anotación no soluciona ni la falta de una autorización ni un cambio de propiedad erróneo. Por lo tanto, no la utilices únicamente para hacer desaparecer un mensaje molesto.

Detección de fallos y funcionamiento seguro

¿Falta el archivo? /sys/kernel/debug/kmemleak, comprueba primero la compilación del kernel que se ha ejecutado realmente y su configuración. CONFIG_DEBUG_KMEMLEAK Debe estar presente; el número de versión de una distribución por sí solo no es suficiente. Anota la compilación y la configuración para que las comparaciones posteriores se realicen sobre la misma base.

Por otra parte, comprueba la Activación en tiempo de ejecución y la incorporación de debugfs. En CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF el parámetro de arranque puede kmemleak=on puede ser necesario. Un archivo que falte no distingue por sí mismo entre estas posibles causas; los cambios en el proceso de arranque o el montaje de «debugfs» deben realizarse en una configuración de prueba autorizada.

Si el resultado de una prueba es nulo, comprueba si el proceso analizado se ha ejecutado realmente y si ha transcurrido suficiente tiempo entre el proceso y el análisis. Repítelo en condiciones documentadas y compáralo con el resultado inicial guardado. Aun así, un informe vacío tiene sus limitaciones: kmemleak no registra todas las asignaciones ni todas las referencias relevantes.

Guarda los resultados existentes antes de realizar cambios en el estado de diagnóstico. La salida puede contener direcciones internas y otra información confidencial; trátala de acuerdo con las normas de acceso y publicación de tu entorno. Realiza las acciones que modifican el estado, preferiblemente, en un sistema de pruebas aislado y autorizado, y ten en cuenta el esfuerzo de diagnóstico adicional sin asumir un porcentaje sin fundamento.

Un elevado consumo de memoria o Presión de memoria Es un problema operativo independiente y, por sí solo, no constituye una prueba de una fuga del núcleo. Para interpretar los tiempos de espera y la escasez de memoria, resulta útil el artículo sobre Presión de memoria en el núcleo de Linux. Combina estas observaciones del funcionamiento con un análisis específico del código y de los resultados, en lugar de deducir la causa directamente a partir de una curva RAM.

Elegir la herramienta de diagnóstico adecuada

Elige la herramienta en función de la supuesta Clase de error, y no solo basándose en el síntoma general del aumento del uso de memoria. kmemleak busca objetos del núcleo que puedan estar huérfanos y que sean compatibles. Para detectar accesos no válidos o problemas de memoria de un proceso de usuario, es recomendable utilizar otra herramienta de instrumentación; cada herramienta responde a preguntas diferentes.

Si se sospecha de una referencia perdida al núcleo, lo primero que viene a la mente es kmemleak. Sin embargo, si el patrón de error indica un acceso fuera de un objeto o a memoria ya liberada, KASAN es la herramienta adecuada para analizar este tipo de casos. KFENCE también rastrea determinados errores de memoria, pero utiliza un enfoque de instrumentación diferente; su disponibilidad e idoneidad dependen del núcleo concreto y del entorno de prueba.

Si se sospecha que el problema se encuentra en un proceso del espacio de usuario, analiza su memoria con una herramienta específica para ello, como Valgrind Memcheck. Un informe de kmemleak sobre objetos del núcleo no sustituye al análisis del montón de una aplicación. Por el contrario, una indicación procedente de un proceso de espacio de usuario no explica automáticamente si un módulo del núcleo está perdiendo memoria.

Para seguir trabajando, elige uno prueba reproducible y documenta la compilación del kernel, la configuración y el proceso. Analiza el ciclo de vida del objeto notificado en el código, corrige la causa detectada y repite el mismo proceso en condiciones lo más similares posible. Compara de nuevo los resultados; el hecho de que no se produzca el error ya de por sí no garantiza que el sistema esté completamente libre de fallos.