Die mysteriösen Umstände für den E1000e-Bug, der zu einer dauerhaften Beschädigung von Intels Gigabit-Netzwerkkarten führen konnte, sind nun geklärt. Ursache ist selbstmodifizierender Code im Ftrace-Subsystem. Ftrace hat erst mit Version 2.6.27 Eingang in den Standardkernel gefunden. Mit Hilfe dieses Subsystems lässt sich die Aufrufreihenfolge von Funktionen protokollieren.

Technisch gesehen fügt dazu der Compiler zu Beginn einer Routine einen speziellen Funktionsaufruf ein. Um diese zusätzlichen Aufrufe in einem produktiven System zu überspringen, überschreibt Ftrace - wenn es abgeschaltet wird - die Maschinenbefehle mit No-Operation-Befehlen (NOP). Dazu merkt sich das Ftrace-System die Adressen der zu überschreibenden Funktionen bei deren erstem Aufruf in einer Liste.

Die Entwickler haben dabei allerdings nicht bedacht, dass Linux die Initialisierungsfunktionen - deren Eigenschaft es ja ist, nur ein einziges Mal aufgerufen zu werden - aus Performancegründen nach dem Durchlaufen aus dem Kernel entfernt. Das wurde dem E1000e-Treiber zum Verhängnis: Nach dem automatischen Entladen der Initialisierungsfunktion hat der Kernel die soeben frei gewordenen Speicherstellen wiederverwertet und dem Treiber per »ioremap« als neue Zugriffsadressen auf die Hardware zugeteilt. Wurde Ftrace dann abgeschaltet, überschrieb es einzelne Teile der Gigabit-Firmware.

Der beim Ersetzen des Funktionsaufrufs sicherheitshalber durchgeführte Check hat dabei leider versagt: An der auszutauschenden Speicherstelle befand sich in der Firmware zufällig der gleiche Code wie jener, den Ftrace austauschen sollte. Die Firmware war danach unbrauchbar. Die Entwickler machen allerdings nicht allein Ftrace für das schwerwiegende Problem verantwortlich.

Auch Intel besserte mit Kernel 2.6.27.1 seinen E1000e-Treiber nach: Aus Sicht der Entwickler darf auch Amok laufender Code kritische Teile nicht überschreiben; ein entsprechender Schutz sei vorzusehen. Kernel 2.6.28 bekommt daher ein gründlich umgebautes Ftrace-Subsystem spendiert. Es modifiziert den Code weiterhin zur Laufzeit, allerdings nur dann, wenn sich dieser auch in einem Textsegment befindet.

Greg Kroah-Hartman hat die Maintainer-Liste um ein Staging-Subsystem erweitert und sich selbst als dessen Betreuer eingetragen. Das neu geschaffene Subsystem verdankt seine Existenz einer Diskussion auf dem Kernel Summit im September 2008. Greg und einige andere Kernelentwickler beschlossen im Hauptzweig des Kernels einen separaten Ort für Treiber zu schaffen, die noch nicht in den Kernel integriert sind.

Mit Hilfe des Staging-Subsystems sollen interessierte Anwender neue Treiber ausprobieren können, ohne sich mit Downloads und Patches zu mühen. Linux-Anwender dürfen im Staging-Bereich allerdings keine voll funktionsfähigen Treiber erwarten. Bedingung für die Aufnahme ins Verzeichnis »drivers/staging/« ist lediglich, dass sich der Quelltext kompilieren lässt. Das Staging-System wird zwar vermutlich einen furchtbaren Code-Verhau anhäufen, es dient jedoch einem wichtigen Zweck, indem es Linux-Anwender und Kernelentwickler einander näher bringt.

Linus Torvalds selbst hat es sich auf die Fahnen geschrieben, neuen Code schneller und unkomplizierter in den Kernel aufzunehmen. Der neue Kernelbereich kann bei dieser Mission helfen, indem er Neuzugängen einen Weg in den Linux-Kern bahnt.

Greg Kroah-Hartman ist Maintainer des neuen Staging-Subsystems, für das er fleißig neue Treiber sammelt.

Sena Seneviratne und David Levy von der Universität Sydney basteln an einer überarbeiteten Anzeige der Systemlast unter Load Average. Statt einer einstelligen Zahl für das gesamte System möchten sie lieber detailliertere Statistiken ausgeben.

Vor allem wollen sie neben der Systemlast zusätzlich die I/O-Last der Festplatten in die Ausgabe aufnehmen. Daneben stellen sie sich eine Anzeige des Load pro User vor, damit jeder Anwender die Auswirkung seines Verhaltens auf das System ablesen kann. Arjan van de Ven ermahnte die beiden dazu, rund 20 Jahre Unix-Tradition nicht einfach über Bord zu werfen - sie sollten lediglich neue Angaben hinzufügen, nicht aber die Berechnung der bestehenden Anzeige verändern.

Der Brite Phillip Lougher hat sich als offizieller Squash-FS-Betreuer in die Datei »MAINTAINERS« eingeschrieben. Bei Squash-FS handelt es sich um ein komprimiertes Dateisystem, das nur lesenden Zugriff erlaubt. Es kommt in Embedded-Systemen und Linux-Live-CDs zum Einsatz. Derzeit beherrscht es nur Gzip-Kompression, da dieser Algorithmus als einziger im Linux-Kernel implementiert ist. Für alle, die das LZMA-Verfahren ausprobieren möchten, gibt es nun jedoch Patches unter [http://www.squashfs-lzma.org].

Von Frederic Weisbecker stammt ein Patch, das dem Big Kernel Lock (BKL) mit einem Tracer zu Leibe rücken soll. Dieses Lock stammt aus der Zeit, als Linux erste SMP-Unterstützung erreichte, es erzeugt aber großen Overhead. Der Tracer misst die Zeitverzögerung, die auf das Konto des BKL geht. Das soll helfen jene Teile des Kernels ausfindig zu machen, aus denen das Big Kernel Lock am ehesten verschwinden sollte.

Linus Torvalds drängt schon lange darauf, das große
Lock zu ersetzen. Das ist allerdings ein schwieriges Unterfangen,
denn nicht immer lässt es sich gegen ein einfaches Lock
austauschen, manchmal sind die Anforderungen komplexer.
Außerdem ist der Locking-Code über viele Stellen des
Kernels verstreut, was eine restlose Entfernung erschwert. Denno