2012-02-05 35 views
5

Tengo un módulo de kernel con errores que estoy tratando de corregir. Básicamente, cuando este módulo se está ejecutando, hará que otras tareas se cuelguen durante más de 120 segundos. Como casi todas las tareas pendientes están esperando mm-> mmap_sem o algunos bloqueos de sistema de archivos (i_node-> i_mutex) sospecho que tiene algo que ver con que este módulo no agarra el bloqueo de mmap_sem y algún nivel de sistema de archivos lock (como inote-> i_mutex) en orden, lo que podría haber causado algún problema de interbloqueo. Sin embargo, dado que mi módulo no intenta tomar esos bloqueos directamente, supongo que es una función a la que llamé la que atrapó esos bloqueos. Y ahora estoy tratando de averiguar qué llamadas de función en mi módulo está causando el problema.Cómo solucionar problemas de interbloqueo en kernel

Sin embargo, estoy teniendo un tiempo difícil para la depuración de las siguientes razones:

  1. No sé exactamente que bloquean la tarea colgado está tratando de agarrar. Recibí el rastro de llamada de la tarea colgada, y sé en qué punto se cuelga. Kernel también me da algún tipo de información como: "1 bloqueo mantenido por automount/3115: 0: (& tipo-> i_mutex_dir_key # 2) {- ..}, en: [] real_lookup + 0x24/0xc5". Sin embargo, quiero saber exactamente qué bloqueo mantiene una tarea, y qué bloqueo exactamente está intentando adquirir para resolver el problema. Como kernel no proporciona los argumentos de las llamadas a funciones junto con el rastreo de llamadas, encuentro que esta información es difícil de obtener.

  2. Estoy usando gdb andvmware para depurar esto, lo que me permite establecer puntos de interrupción, paso a una función y tal. Sin embargo, como qué tarea y en qué punto se colgará esa tarea es algo no determinista, realmente no sé dónde establecer puntos de interrupción e inspeccionar. Sería genial si de alguna manera puedo "adjuntar" a la tarea que el kernel reportó estar bloqueada por más de 120 segundos, y obtener algo de información al respecto.

Así que mis preguntas son las siguientes:

  1. ¿Dónde puedo conseguir, junto con el rastreo de llamadas, los argumentos de las funciones en el rastreo de llamadas, con el fin de averiguar exactamente que bloquean una tarea está tratando de agarrar.

  2. ¿Es posible para mí usar gdb para "adjuntar" de alguna manera a una tarea colgada en un kernel? Si no, ¿hay alguna forma de que al menos examine la estructura de datos que representa esa tarea? Como estoy teniendo dificultades para examinar toda la estructura de datos global en kernel también. GDB siempre se queja de que "no puede acceder a la memoria 0x3200" o algo similar.

  3. También sería muy útil si puedo imprimir para cada tarea en el kernel, qué bloqueos tienen actualmente. ¿Hay una manera de hacerlo?

Muchas gracias!

Respuesta

3

No respondiendo su pregunta directamente, pero espero que esto sea más útil: el kernel de Linux tiene un validador de bloqueo de servicio pesado llamado lockdep. Enciéndalo y déjelo funcionar. Si tiene un problema de bloqueo, es probable que lo atrape y le proporcione un informe detallado.

Ver: http://www.mjmwired.net/kernel/Documentation/lockdep-design.txt

Cuestiones relacionadas