2011-05-06 13 views
9

Para probar el comportamiento del kernel cuando pierde memoria, estoy escribiendo un módulo kernel que continuamente asigna memoria, p. el código se ve comocómo determinar si un módulo del kernel de Linux tiene una pérdida de memoria

int bytesLeaked = 128000; 
char *var = kmalloc(bytesLeaked, GFP_KERNEL); 
if (var != NULL) 
printk("leaked %d bytes at address %x\n", bytesLeaked, (unsigned int)var); 

Este código está en el init_module. Tengo las siguientes preguntas

  1. ¿Cómo puedo determinar si el código ha filtrado la memoria? lsmod no revela mucho.
  2. Los tutoriales en Internet solo muestran el código en init_module y exit_module. ¿Qué pasa si deseo hacer la asignación de memoria durante un período de tiempo después de que se haya insertado el módulo pero antes de salir?
  3. ¿Es posible para mí escribir código que gotea la memoria solo cuando el usuario le da una instrucción para que lo haga, p. ¿Puede un programa de espacio de usuario hacer una llamada al sistema que hará que el módulo pierda memoria?

Respuesta

0
  1. Código pérdidas de memoria cuando se asigna un bloque de memoria (por ejemplo, con kmalloc()) y luego pierde todas las referencias a ese bloque de memoria sin liberar primero. Su código no lo ha hecho, ya que todavía tiene var en alcance y apuntando a su bloque de memoria. Si agrega var = NULL; en la línea siguiente, entonces tiene una pérdida de memoria de buena fe.

  2. Y es absolutamente posible tenerlo para que un evento en el espacio de usuario active su módulo kernel para comenzar a asignar memoria. No estoy seguro si puede hacerlo directamente a través de una llamada al sistema, pero si no puede, entonces hay varias otras maneras de realizar la tarea. Solo necesita elegir uno e implementarlo. Incluso algo tan simple como tener un archivo predeterminado que touch cada vez que desee activar una asignación de memoria debería funcionar. Aunque no veo por qué no puede hacer que su código init_module engendre un hilo que solo asigna memoria periódicamente con el tiempo, si ese es el comportamiento que desea.

+4

re 1: La propiedad de definición de una pérdida de memoria es que la asignación nunca se libera, no necesariamente que no hay referencias a la misma. Además, 'var' presumiblemente está fuera de alcance en algún momento, momento en el que su recuento de referencias va a 0 de todos modos. (Vamos a ignorar el hecho de que "referencia" no está bien definido en el lenguaje C.) – Karmastan

+0

Gracias. Traté de codificar para generar hilos, pero el código es bastante complejo http://www.scs.ch/~frey/linux/kernelthreads.html. ¿Serás capaz de proporcionar una idea de cómo puedo activar la asignación de memoria a través de un evento de espacio de usuario sin una llamada al sistema? – kakinada

+0

KEDR es compatible con las versiones 2.6.31 o posteriores del kernel. El mío es 2.6.28. Parece que KEDR no se puede usar. Trataré de encontrar herramientas similares para el kernel que tengo – kakinada

18

Si es necesario comprobar si un módulo del kernel se ha filtrado la memoria y la máquina tiene una arquitectura x86, puede utilizar KEDR system, que incluye un detector de fugas de memoria.

KEDR no requiere que reconstruya el kernel. Los documentos en línea (consulte "Primeros pasos", por ejemplo) describen cómo instalar y usar KEDR. En resumen, el procedimiento es el siguiente.

de instalación (de origen): Archivo fuente de untar - cmake < ...> - hacer - make install

inicio KEDR antes de cargar el módulo:

$ kedr start <name_of_the_module_to_analyze> -f leak_check.conf 

, puede cargar su módulo y trabaja con eso como de costumbre. Después de descargarlo, KEDR le dará un informe en debugfs (por lo general debugfs se monta en /sys/kernel/debug), por ejemplo:

$ cat /sys/kernel/debug/kedr_leak_check/info 
Target module: "...", 
Memory allocations: 3 
Possible leaks: 2 
Unallocated frees: 0 

El archivo possible_leaks de /sys/kernel/debug/kedr_leak_check/ proporciona información (dirección, el tamaño, la pila de llamadas) sobre cada filtrada bloque de memoria.

Por último, puede dejar de KEDR (nota que /sys/kernel/debug/kedr_leak_check/ desaparecerán):

kedr stop 

Si está utilizando un sistema con una arquitectura diferente a la x86, Kmemleak también puede ser útil, aunque es un poco más difícil de utilizar. Probablemente necesite reconstruir el kernel con el parámetro CONFIG_DEBUG_KMEMLEAK establecido en 'y'. Aún así, Kmemleak es una herramienta muy útil también. Ver Documentation/kmemleak.txt en las fuentes del núcleo para más detalles.

+2

KEDR admite 2.6.31 o versiones de kernel más nuevas. El mío es 2.6.28. Parece que KEDR no se puede usar. Trataré de encontrar herramientas similares para el kernel que tengo – kakinada

Cuestiones relacionadas