Wie man Deadlock-Probleme im Kernel debuggt

Question

Ich habe ein fehlerhaftes Kernelmodul, das ich zu beheben versuche. Grundsätzlich verursacht dieses Modul, wenn es läuft, dass andere Aufgaben für mehr als 120 Sekunden hängen bleiben. Da fast alle hängenden Aufgaben entweder auf mm->mmap_sem oder auf einige Dateisystemsperrer (i_node->i_mutex) warten, vermute ich, dass es damit zu tun hat, dass dieses Modul den mmap_sem-Sperrmechanismus und einige Dateisystem-Sperrmechanismen (wie inote->i_mutex) nicht in der richtigen Reihenfolge abruft, was möglicherweise ein Deadlock-Problem verursacht hat. Da mein Modul jedoch nicht versucht, diese Sperren direkt zu bekommen, gehe ich davon aus, dass es eine Funktion ist, die ich aufgerufen habe, die diese Sperren übernimmt. Und nun versuche ich herauszufinden, welche Funktionsaufrufe in meinem Modul das Problem verursachen.

Allerdings habe ich Schwierigkeiten, es aus folgenden Gründen zu debuggen:

1. Ich weiß nicht genau, welche Sperre die hängende Aufgabe zu bekommen versucht. Ich habe den Aufrufverlauf der hängenden Aufgabe erhalten und weiß, an welcher Stelle sie hängt. Der Kernel gibt mir auch irgendwelche Informationen wie: "1 Sperre gehalten von automount/3115: 0: (&type->i_mutex_dir_key#2){--..}, at: [] real_lookup+0x24/0xc5". Ich möchte jedoch genau wissen, welche Sperre eine Aufgabe hält und genau welche Sperre sie zu erwerben versucht, um das Problem herauszufinden. Da der Kernel die Argumente der Funktionsaufrufe nicht zusammen mit dem Aufrufverlauf bereitstellt, finde ich diese Informationen schwer zu erhalten.

2. Ich verwende gdb undvmware, um dies zu debuggen, was es mir ermöglicht, Haltepunkte zu setzen, in eine Funktion einzutreten usw. Da jedoch unklar ist, bei welcher Aufgabe und an welcher Stelle diese hängen wird, weiß ich nicht wirklich, wo ich Haltepunkte setzen und überprüfen soll. Es wäre großartig, wenn ich irgendwie "anhängen" könnte an die Aufgabe, von der der Kernel berichtete, dass sie für mehr als 120 Sekunden blockiert ist, und einige Informationen darüber erhalten könnte.

Also lauten meine Fragen wie folgt:

1. Wo kann ich zusammen mit dem Aufrufverlauf die Argumente der Funktionen im Aufrufverlauf erhalten, um genau herauszufinden, welche Sperre eine Aufgabe zu bekommen versucht.

2. Ist es mir möglich, gdb zu verwenden, um irgendwie an eine hängende Aufgabe im Kernel "anzuhängen"? Wenn nicht, gibt es einen Weg für mich, zumindest die Datenstruktur zu untersuchen, die diese Aufgabe repräsentiert? Da ich auch Schwierigkeiten habe, alle globalen Datenstrukturen im Kernel zu untersuchen. GDB beschwert sich immer "kann nicht auf Speicher 0x3200 zugreifen" oder etwas Ähnliches.

3. Es wäre auch sehr hilfreich, wenn ich für jede Aufgabe im Kernel ausgeben könnte, welche Sperren sie aktuell hält. Gibt es einen Weg das zu tun?

Vielen Dank!

Answer 1

Nicht direkt auf Ihre Frage antworten, aber hoffentlich ist dies hilfreicher - der Linux-Kernel verfügt über einen eingebauten Heavy-Duty-Schlossvalidierer namens lockdep. Aktivieren Sie es und lassen Sie es laufen. Wenn Sie ein Problem mit der Schlossreihenfolge haben, wird es wahrscheinlich erkannt und Ihnen einen detaillierten Bericht geben.

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

Answer 2

Das Kernel-Feature lockdep kann Ihnen in diesem Zusammenhang helfen. Schauen Sie sich meinen Beitrag an, wie Sie es in Ihrem Kernel verwenden können: So verwenden Sie die lockdep-Funktion im Linux-Kernel zur Erkennung von Deadlocks

Answer 3

Lass mich es versuchen. 1) Versuche KGDB

2) Du meinst einen hängenden Prozess? http://www.ibm.com/developerworks/aix/library/au-unix-strace.html

3) Vielleicht versuchst du das lsof Paket.