Das Problem

Doch mit dieser Entscheidung begann die Misere: Der frische Kernel 4.2 bootete zwar ohne Murren und erlaubte auch den Login per SSH. Sobald Openstack jedoch virtuelle Maschinen auf dem System starten wollte, verabschiedete sich der Kernel mit einer hässlichen Panic-Meldung. Das Problem war zuverlässig zu reproduzieren, lediglich der Stack-Trace wies Unterschiede zwischen den einzelnen Crashes auf. Als Stack-Trace bezeichnet der Kernel eine Liste aufgerufener Funktionen kurz vor dem Absturz: Mit dieser Information ist es leichter, die Programmfunktion im Kernel zu finden, die den Absturz auslöst.

• 

Während dieser Stack-Trace klare Rückschlüsse auf das Problem zulässt ... (Screenshot Martin Loschwitz)

Noch jemand mit diesem Problem?

Der erste Schritt auf der Suche nach einer Lösung war die Suche nach Leidensgenossen. Im Fedora-Bugtracker fand sich tatsächlich ein interessanter Fehlerbericht: Die dort beschriebenen Umstände entsprachen etwa denen der lokalen Umgebung, in welcher das Problem ebenfalls auftrat.

Wenig Hoffnung gab die dokumentierte Aktivität des Bugreports: Antworten der Fedora- oder Red-Hat-Entwickler gab es nicht. Letztlich blieb nur, einen entsprechenden Kommentar zu hinterlassen und damit zu dokumentieren, dass man das Problem ebenfalls hatte.

Beim Hersteller melden

Weil das Problem akut nur auf Ubuntu zu reproduzieren war, war der nächste logische Schritt, einen Bug-Report in Launchpad anzulegen, dem Ubuntu-Bug-Tracker. Um einen aussagekräftigen Fehlerbericht zu schreiben, war allerdings eine weitergehende Analyse des Problems angesagt. Schnell war klar, dass das Problem in irgendeiner Weise mit der Speicherverwaltung des Linux-Kernels zu tun haben musste: Die Funktion "kmem_cache_alloc" tauchte zwar nicht in jedem Stack-Trace auf, aber doch in den meisten. Auffällig war außerdem, dass der eigentliche Crash fast immer in "fuse_direct_io" auftrat, einer Funktion, die ebenfalls Speicher im Kernel für sich beansprucht.

Damit gab es eine erste Arbeitshypothese: Aus bisher unbekanntem Grund ging bei der Verwendung von Arbeitsspeicher im Fuse-Treiber des Linux-Kernels etwas schief. Programmfunktionen von Fuse wollten deshalb auf Speicherbereiche zugreifen, die ihnen nicht gehörten. Der Rest war hinlänglich dokumentiertes Standard-Verhalten: Der Linux-Kernel stirbt in solchen Fällen den Panic-Tod und nötigt den Admin zum Reboot.

• 

..., erwähnt dieser Fuse mit keinem Wort. Die Ursache für den Crash ist in beiden Fällen allerdings dieselbe. (Screenshot Martin Loschwitz)

Es war also klar, dass es mit Linux 4.2 vorerst nichts werden würde. Bis auf einen Server durchliefen alle Systeme ein Downgrade auf Linux 3.19.