• IT-Karriere:
  • Services:

Linux-Kernel: Machine-Learning allein findet keine Bugs

Mittels KI sucht der Linux-Kernel-Entwickler Sasha Levin nach Patches für die stabilen Zweige, die Code verbessern. Aber kann er mit dem System auch Patches finden, die Bugs enthalten? Für Levin ist das eine schwer lösbare Aufgabe, aber er hat ein paar Anhaltspunkte dafür, wie das gehen könnte.

Artikel veröffentlicht am ,
Fehler im Linux-Kernel zu finden, bevor der Code eingepflegt wird, geht wohl nicht.nur mit Machine Learning.
Fehler im Linux-Kernel zu finden, bevor der Code eingepflegt wird, geht wohl nicht.nur mit Machine Learning. (Bild: Liam Quinn,flickr.com/CC-BY-SA 2.0)

Der bei Microsoft angestellte Entwickler Sasha Levin pflegt gemeinsam mit Greg Kroah-Hartman die sogenannten Stable-Zweige des Linux-Kernels. Um die dafür notwendigen Patches für Verbesserungen zu finden, setzt Levin unter anderem auf einen Machine-Learning-Ansatz. Wie der Entwickler in seinem Vortrag auf dem diesjährigen Open Source Summit Europe in Lyon berichtet, sei er wegen seiner Arbeiten mehrfach gefragt worden, ob damit nicht auch Bugs gefunden werden könnten, bevor diese überhaupt in den Kernel eingepflegt werden. Die Antwort darauf ist laut Levin aber alles andere als einfach, wie er in einer ausführlichen Analyse vorstellt.

Stellenmarkt
  1. Scheidt & Bachmann GmbH, Mönchengladbach
  2. SWB Bus und Bahn, Bonn

Denn wie viele Entwickler wissen, ist das Erkennen von fehlerhaftem Code keine überschaubare Aufgabe. Zwar gebe es bereits eine Vielzahl von Werkzeugen zum Auffinden von Fehlern, etwa per statischer Code-Analyse. Doch aus Sicht von Levin ist die größte Fehlerquelle in der Entwicklung des Linux-Kernels dessen Entwicklungsprozess selbst. Das versucht der Entwickler durch eigene Analysen zu untermauern.

Objektive Analyse schwer umsetzbar

Aus seiner persönlichen Erfahrung als Maintainer weiß Levin, dass vor allem Reviews, also das Überprüfen des Codes durch Dritte, sowie das Testen von Code das Einführen von Bugs vermeiden helfen. Dabei spiele es durchaus eine Rolle, wer das Review durchführt, wie viel Zeit dies in Anspruch nimmt oder auch wie ausführlich die mögliche Kritik dazu ausformuliert wird.

Zwar sei es schwierig, diese und weitere Dinge tatsächlich zu quantifizieren. Das gelte vor allem auch für die Frage, was im Sinne der ursprünglichen Fragestellung und Untersuchung überhaupt als Bug gewertet werden sollte. Dennoch habe Levin versucht, einige dieser Überlegungen an Hand einer vorausgewählten Menge von Code-Beiträgen zum Kernel in ein Machine-Learning-Modell zu überführen.

Das Modell hat dabei natürlich zwangsläufig Schwächen und kann auch nicht direkt dafür benutzt werden, um tatsächlich fehlerhaften Code zu finden, bevor dieser in den Hauptzweig des Kernels eingepflegt wird. Für Levin bietet die so durchgeführte Untersuchung dennoch einige sehr wichtige Anhaltspunkte.

Schnelle Patches kurz vor der Deadline haben mehr Bugs

Die wohl wichtigste Erkenntnis hierbei ist laut Levin, dass die Wahrscheinlichkeit Fehler in Beiträgen einzuführen, dreimal höher ist als normal, wenn der Code erst spät in RC-Kernel eingepflegt wird. Das erscheint zunächst kontraintuitiv, da nach einer zweiwöchigen Phase zum Einreichen neuer Funktionen für die kommende Linux-Version (Merge-Window) eine meist achtwöchige Testphase mit Bug-Fixes und den Release-Candidates (RC) folgt, bevor eine neue Linux-Version erscheint.

Laut Levin bestätigt dieses Ergebnis aber seine Vermutungen in Bezug auf die Reviews. So durchlaufen neue Funktionen und größere Änderungen oft eine lange Review-Phase und die Patches dazu werden meist ausgiebig diskutiert. In der späten RC-Phase der Kernel-Entwicklung ist der Prozess zum Einpflegen jedoch sehr viel schneller und oft finde gar kein Review statt.

Levin habe für diese Entwicklungsphase eine Menge Patches gefunden, deren Code an einzigem Tag geschrieben, eingereicht und eingepflegt worden ist. Bei einer derart schnellen Entwicklung steigt natürlich das Fehlerpotenzial.

Ob und was aus dieser Erkenntnis aber langfristig für den Entwicklungsprozess des Linux-Kernels folgt, ist für Levin nicht wirklich klar. Er habe zwar einige Ideen, diese ließen sich wohl aber nur schwer umsetzen. Dazu gehöre etwa eine echte Freeze-Phase in der Entwicklung, um die Neuerungen ausgiebig zu testen. Möglicherweise verschiebt das das Einpflegen kurzfristig erstellter Patches aber auch nur weiter nach hinten.

Ebenso könnte sich Levin eine Art standardisiertes Vorgehen zur Akzeptanz von Patches in den Hauptzweig vorstellen. Als Voraussetzung für eine Aufnahme könnte hierbei eine Mindestanzahl an Tagen sein, die die Patches in dem Linux-Next-Zweig vor Aufnahme in den Hauptzweig vorhanden sein müssen. Ebenso könnten ausführliche Reviews oder Tests erzwungen werden oder auch sogenannte Sign-off-Tags. Letztere würden in diesem Fall in etwa "abgesegnet von" bedeuten.

All diese Vorgaben würden laut Levin bei einem nicht vernachlässigbaren Anteil an Entwicklern und Maintainern wohl auf Widerstand stoßen und sind damit nicht umsetzbar.

Bitte aktivieren Sie Javascript.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
  • ohne Werbung
  • mit ausgeschaltetem Javascript
  • mit RSS-Volltext-Feed


Anzeige
Hardware-Angebote
  1. täglich neue Deals bei Alternate.de
  2. 419,00€ (Bestpreis!)
  3. 555,55€ (zzgl. Versandkosten)

Eheran 30. Okt 2019 / Themenstart

In der Statistik eben genau nicht. Da bleiben die Standardabweichungen der Wert gleich...

schnedan 30. Okt 2019 / Themenstart

KI ist ein Brute-Force Tool, das man nimmt um schnell eine 80% Lösung zu haben, das man...

Kommentieren


Folgen Sie uns
       


Pixel 4 XL - Test

Das Pixel 4 XL ist Googles erstes Smartphone mit einer Dualkamera. Im Test haben wir uns diese genau angeschaut.

Pixel 4 XL - Test Video aufrufen
ZFS erklärt: Ein Dateisystem, alle Funktionen
ZFS erklärt
Ein Dateisystem, alle Funktionen

Um für möglichst redundante und sichere Daten zu sorgen, ist längst keine teure Hardware mehr nötig. Ein Grund dafür ist das Dateisystem ZFS. Es bietet Snapshots, sichere Checksummen, eigene Raid-Level und andere sinnvolle Funktionen - kann aber zu Anfang überfordern.
Von Oliver Nickel

  1. Dateisystem OpenZFS soll einheitliches Repository bekommen
  2. Dateisystem ZFS on Linux unterstützt native Verschlüsselung

Fritzbox mit Docsis 3.1 in der Praxis: Hurra, wir haben Gigabit!
Fritzbox mit Docsis 3.1 in der Praxis
Hurra, wir haben Gigabit!

Die Fritzbox 6591 Cable für den Einsatz in Gigabit-Kabelnetzen ist seit Mai im Handel erhältlich. Wir haben getestet, wie schnell Vodafone mit Docsis 3.1 tatsächlich Daten überträgt und ob sich der Umstieg auf einen schnellen Router lohnt.
Ein Praxistest von Friedhelm Greis

  1. Nodesplits Vodafone bietet 500 MBit/s für 20 Millionen Haushalte
  2. Sercomm Kabelmodem für bis zu 2,5 GBit/s vorgestellt
  3. Kabelnetz Die Marke Unitymedia wird verschwinden

Need for Speed Heat im Test: Temporausch bei Tag und Nacht
Need for Speed Heat im Test
Temporausch bei Tag und Nacht

Extrem schnelle Verfolgungsjagden, eine offene Welt und viel Abwechslung dank Tag- und Nachtmodus: Mit dem Arcade-Rennspiel Heat hat Electronic Arts das beste Need for Speed seit langem veröffentlicht. Und das sogar ohne Mikrotransaktionen!
Von Peter Steinlechner

  1. Electronic Arts Need for Speed Heat saust durch Miami

    •  /