• 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. operational services GmbH & Co. KG, Berlin
  2. BIG direkt gesund, Dortmund

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
Top-Angebote
  1. 159,90€ (Bestpreis!)
  2. (u. a. HP Pavilion 32 Zoll Monitor für 229,00€, Steelseries Arctis Pro wireless Headset für 279...
  3. ab 62,99€
  4. (aktuell u. a. HyperX Alloy Elite RGB Tastatur für 109,90€, Netgear EX7700 Nighthawk X6 Repeater)

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
       


Google Pixel 4 und Pixel 4 XL ausprobiert

Google hat seine neuen Pixel-Smartphones vorgestellt: Im ersten Hands on machen das Pixel 4 und das Pixel 4 XL einen guten Eindruck.

Google Pixel 4 und Pixel 4 XL ausprobiert Video aufrufen
Autonomes Fahren: Wenn der Wagen das Volk nicht versteht
Autonomes Fahren
Wenn der Wagen das Volk nicht versteht

VW testet in Hamburg das vollautonome Fahren in der Stadt - und das recht erfolgreich, wie eine Probefahrt zeigt. Als größtes Problem erweist sich ausgerechnet die Höflichkeit der Fußgänger.
Ein Bericht von Werner Pluta

  1. Volkswagen ID. Space Vizzion als Elektrokombi vorgestellt
  2. Elektroauto von VW Es hat sich bald ausgegolft
  3. ID.3 kommt Volkswagen verkauft den E-Golf zum Schnäppchenpreis

In eigener Sache: Aktiv werden für Golem.de
In eigener Sache
Aktiv werden für Golem.de

Keine Werbung, kein unerwünschtes Tracking - kein Problem! Wer Golem.de-Inhalte pur nutzen möchte, hat neben dem Abo Golem pur jetzt eine weitere Möglichkeit, Golem.de zu unterstützen.

  1. Golem Akademie Von wegen rechtsfreier Raum!
  2. In eigener Sache Wie sich Unternehmen und Behörden für ITler attraktiv machen
  3. In eigener Sache Unser Kubernetes-Workshop kommt auf Touren

Surface Laptop 3 (15 Zoll) im Test: Das 15-Zoll-Macbook mit Windows 10 und Ryzen
Surface Laptop 3 (15 Zoll) im Test
Das 15-Zoll-Macbook mit Windows 10 und Ryzen

Was passiert, wenn ein 13-Zoll-Notebook ein 15-Zoll-Panel erhält? Es entsteht der Surface Laptop 3. Er ist leicht, sehr gut verarbeitet und hat eine exzellente Tastatur. Das bereitet aber nur Freude, wenn wir die wenigen Anschlüsse und den recht kleinen Akku verkraften können.
Ein Test von Oliver Nickel

  1. Surface Laptop 3 mit 15 Zoll Microsoft könnte achtkernigen Ryzen verbauen

    •  /