Verbesserung der EBPF -Tests im Kernel

Als Teil von a Partnerschaft mit dem EBPF FoundationBootlin -Ingenieure Bastien Curutchet Und Alexis Lothoré Arbeiten mit der Kernel -Community zusammen, um die EBPF -Unterstützung im Kernel in verschiedenen Aspekten zu verbessern. Dieser Beitrag ist der erste von einer Serie, die diese Bemühungen hervorhebt. Für diejenigen, die die EBPF -Technologie einholen müssen, können Sie sich unsere ansehen.Linux -Debugging, Verfolgung und Profilerstellung”Trainingskurs, der gewesen ist Kürzlich aktualisiert Mit EBPF -Grundlagen!

Während EBPF seit vielen Jahren im Linux -Kernel unterstützt wurde, erhält er immer wieder viele neue Funktionen und Korrekturen mehr als 300 neue Commits im EBPF -Subsystem). Infolgedessen und ähnlich wie bei jedem anderen Teil des Kernels ist es sowohl für Entwickler als auch für die Betroren von entscheidender Bedeutung, zu überprüfen, ob keine Regression durch neue Änderungen eingeführt wird. Dieses Bedürfnis ist noch dringlicher, da einige Teile des EBPF-Subsystems wie der Verifizierer oder die architekturspezifischen JIT-Module selbst für erfahrene Entwickler sehr komplex sein können. Um dies anzugehen, ist das EBPF -Subsystem von abgedeckt ein Satz „Selbsttests“ Direkt im Kernel -Quellbaum leben. Diese Selbsttests bestehen aus mehreren Teilen, die wichtigsten sind:

• EBPF -Programme, mit denen einige bestimmte Teile des Subsystems ausüben konzipiert werden
• Benutzerspace -Programme entweder in C oder Bash, die die EBPF -Programme manipulieren und die Stimuli und die entsprechenden Überprüfungen tatsächlich ausführen
• Makefiles zum Bau all dieser Komponenten
• A vmtest.sh script Dies erleichtert die Ausführung der Tests: Es kann eine Kernelkonfiguration laden, die für die Tests zugeschnitten ist, sie erstellt, die Tests erstellen, ein Root -Dateisystem abrufen, eine virtuelle Maschine mit dem frisch gebauten Kernel starten und dann Tests ausführen. Dieses Skript ist sogar in der Lage, verschiedene Architekturen für die emulierte Plattform zu bearbeiten.

So kann man den Kernel -Quellcode sehr leicht mit dem Hacken von Kernel -Code beginnen und prüfen, ob der EBPF -Kern mit nur wenigen Befehlen immer noch wie erwartet funktioniert:

$ git clone https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git linux
$ cd linux
$ # Add some code to add a new feature in the eBPF core
$./tools/testing/selftests/bpf/vmtest.sh # Ensure that we did not break anything

Während diese Tests eine starke Grundlage für die Erkennung von Regressionen bestehen Die EBPF -MailinglisteDie Patchwork -Framework verwendet von Betreuern, um Beiträge zu bewältigen und a Dediziertes Github -Repository in der Lage zu laufen Spezifische Github -Aktionen. Dieser gesamte Satz ermöglicht die systematische Prüfung eines von Entwicklern gesendeten Codes zur Integration in das EBPF -Subsystem. Der grundlegende Workflow ist der folgende:

• Ein Entwickler implementiert eine neue Funktion oder ein Fix und möchte sie in den vorgelagerten Kernel integrieren lassen
• Er bereitet seine Commits vor und schickt diese an [email protected] zur Überprüfung
• Sobald die Serie veröffentlicht wurde, wählt das GitHub -Test -Repository den Seriencode automatisch aus, rebase ihn über den aktuellen EBPF -Integrationsbaum und öffnet damit eine Pull -Anfrage.
• Diese Pull -Anfrage führt dann automatisch eine Matrix von Tests im eingereichten Code aus. Diese Tests replizieren das oben beschriebene Verhalten für vMtest.sh für verschiedene Architekturen (derzeit unterstützt die Automatisierung X86, ARM64 und S390) und verschiedene Aromen und Versionen von Compilern.
• Sobald alle Tests durchgeführt wurden, wird der Serienstatus auf Patchwork aktualisiert, damit die Wardner die Gesamtauswirkungen der Serie auf die vorhandene Codebasis schnell überprüfen können. Der Mitarbeiter erhält auch den CI -Auslaufstatus per Post.

Diese gesamte Automatisierung ermöglicht es den Erziehern und Entwicklern, Regressionen so früh wie möglich zu erkennen (bevor der Code integriert ist), ohne alle EBPF-Funktionen manuell neu zu testen, was offensichtlich ein großer Overhead im Beitragsprozess wäre. Mit großer Verantwortung sind jedoch große Verantwortung: Mitwirkenden, die den neuen Code stromaufwärts senden, wird erwartet, dass sie die Tests bereitstellen, die den Code integrieren möchten, um sicherzustellen, dass er auch jedes Mal getestet wird, wenn er in Zukunft durch eine gewisse Änderung beeinflusst wird.

Es ist auch erwähnenswert, dass eine Person manuell einen CI -Lauf in seinem Code auslösen kann, ohne eine Serie an die Mailingliste senden zu müssen. Die einzige Anforderung ist, ein Github -Konto zu erhalten, dann kann er:

• Gabel Das offizielle Test -Repository auf seinem Github -Konto
• Drücken Sie den Code, der auf der Gabel auf eine dedizierte Filiale getestet wird (nennen wir ihn an code_under_test)
• Öffnen Sie manuell eine Pull -Anfrage und bitten Sie, die Commits von der zu integrieren code_under_test Zweig zum BPF-Next_Base Zweig

Diese Pull -Anfrage wird nicht von den EBPF -Wartemitteln überwacht, da die offizielle Methode zum beitragen Code darin besteht, die Mailinglisten zu verwenden. Es wird jedoch die gesamte CI -Automatisierung auslösen, ähnlich wie die automatischen Pull -Anfragen für die in der Mailingliste gesendete Serie.

Leider kann die CI -Automatisierung nicht ausgeführt werden alle die Tests in der vorhanden Tools/Test/Selbsttests/BPF Verzeichnis im Kernel -Quellbaum. Der Einstiegspunkt für die Ausführung von Tests in CI ist eine Reihe von generischen „Läufern“, die nichts anderes sind als generische Programme, die bestimmte Befehle und Konfigurationen empfangen können, um:

• Listen Sie alle unterstützten Tests auf
• Führen Sie eine bestimmte Liste von Tests aus und filtern Sie einige spezifische Tests heraus
• Konfigurieren Sie Tests Parallelisierung
• Testprotokolle generieren
• usw

Der Haupt -Testläufer für EBPF -Tests ist Test_ProgsAber wir können auch einige spezifischere Läufer für einige spezifischere Themen finden, wie wie test_mapsAnwesend test_verifier oder Veristat. Wenn Sie sich die von der CI -Automatisierung generierten Protokolle ansehen, werden Sie beispielsweise feststellen, dass VMTest die Ergebnisse von Test_Progs tatsächlich ausgeführt und überwacht.

Die direkte Folge dieser Organisation ist, dass jeder Test, der die Chance hat, in CI zu laufen, in einen der Testläufer integriert werden muss. Dies ist im Allgemeinen eine leichte Aufgabe beim Erstellen eines neuen Tests, dank all der harten Arbeit, die bereits von den Testläufern und den entsprechenden Makefiles behandelt wird. Entweder aus historischen oder technischen Gründen werden viele Tests nicht so integriert: Sie werden im Allgemeinen aus benutzerdefinierten Skripten und eigenständigen Binärdateien bestehen, ihre eigenen spezifischen Eingaben einnehmen und ein eigenes Format für die Testausgabe haben.

Diese Tests sind zwar für die Funktionen, die sie abdecken, nicht so nützlich wie möglich, da wir sie manuell ausführen müssen, um zu überprüfen, ob die gezielten Funktionen wie erwartet funktionieren. Hier sind die Bootlin -Ingenieure auf Anfrage der EBPF -Stiftung eingestiegen, um diese eigenständigen Tests zu sortieren: Jedes dieser muss ordnungsgemäß konvertiert und in die generischen Testläufer integriert werden, damit sie automatisch auf Serie gesendet werden können.

Die Konvertierung dieser Tests beinhaltete jedes Mal so gut wie der gleiche Prozess. Die meisten von ihnen müssen in den TEST_PROGS -Läufer integriert werden, ein C -Programm. Das Makefile für Test_Progs erkennt Funktionen automatisch mit einem bestimmten Muster im Namen und erleichtert das Erstellen neuer Tests. Es ist auch in der Lage, die erforderlichen EBPF -Programme automatisch zu erstellen und die entsprechenden zu generieren libbpf Skelette vom UserSpace -Teil des Tests verwendet werden. Um einen Test in den TEST_PROGS -Läufer umzuwandeln, müssen wir dann:

• Setzen Sie das vom Test benötigte EBPF -Programm (en) in die Progs Verzeichnis
• Erstellen Sie den tatsächlichen Test (den UserSpace -Teil) in der prog_tests Verzeichnis
  • Es handelt sich um eine C -Datei mit mindestens einer Funktion, die von vorangestellt wurde prüfen_ (oder serial_test_ Für Tests, die nicht parallel ausgeführt werden können), wodurch es automatisch in die endgültigen test_progs binären integriert wird
  • Es ist in der Lage, einige Test_Progs -Helfer sowie einige Netzwerkhelfer zu verwenden, um beispielsweise ein bestimmtes Netzwerk -Setup zu konfigurieren
• Verschieben Sie den Inhalt vom Test „Standalone“ in die neue Testdatei

Obwohl der Gesamtprozess recht einfach aussieht, war diese Aufgabe offensichtlich mit einigen Herausforderungen und Besonderheiten für jeden Test verbunden:

• Einige Tests stützen sich auf ein bestimmtes Hardware -Setup, das in der CI -Umgebung nicht verfügbar ist Qemu. Wenn Tests von Test_Progs beispielsweise von Netzwerkschnittstellen abhängen, verwenden sie im Allgemeinen die Loopback -Schnittstelle oder ein Paar von davon Virtuelle Schnittstellen. Trotz dieser Lösungen müssen Entwickler trotz der Konvertierung zu Test_Progs eine Version einiger Tests aufbewahren, die auf echten Hardware ausgeführt werden können.
• Einige Tests validieren den zu testenden Code nicht mit einem reinen „funktionalen“ Ansatz, sondern durch das Sammeln einiger Metriken (z. B. die auf einer Schnittstelle gemessene Netzwerkbande) und vergleichen ihn mit einem Schwellenwert. Dieser Ansatz macht es schwierig, robuste und wiederholbare Ergebnisse in CI zu haben, sodass der Weg von validieren Der Test muss geändert werden.
• Die eigenständigen Tests sind im Allgemeinen nicht so konzipiert, dass sie parallel zu anderen Tests durchgeführt werden (was für Tests in Test_Progs der Fall ist, um die Ausführungszeit angemessen zu halten), sodass ihr Standardverhalten im Allgemeinen zu Konflikten und Rassenbedingungen mit anderen Tests führt: Zum Beispiel kann es versuchen, die volle Kontrolle einer Ressource blind zu ergreifen (z. B. eine bestimmte Netzwerkschnittstelle), die zwischen allen Tests geteilt werden müssen), die zwischen allen Tests geteilt werden müssen), was gemeinsame Tests hat), was auf allen Tests geteilt werden muss). Diese Art von Test muss dann etwas Arbeit benötigen, um beispielsweise richtig isoliert zu sein, beispielsweise mit Namespaces.
• Eine besondere Aufmerksamkeit muss beim Hinzufügen neuer Tests auf die CI -Leistung gerichtet werden: Die benötigte Zeit zum Durchführen der CI -Tests muss vernünftig bleiben, damit wir schnell genug Ergebnisse erzielen können, sodass wir vorsichtig mit dem von jedem konvertierten Test eingeführten Overhead sein müssen.

Einige dieser Themen führten zu mehr Kopienkratzern als andere, aber dank der Feedback der Community und einige gezielte Refactoring wurden diese angegangen und haben manchmal sogar zu einigen allgemeinen Verbesserungen der Testläufer geführt.

Vor Beginn von Bootlins Arbeiten zum Projekt bekam der Kernel -Quellbaum Rund 34 Shell -Skripte für Tests (ignorieren diejenigen, die Benchmarking anstelle von Funktionstests durchführen, und vmtest.sh). Zum Zeitpunkt des Schreibens dieses Beitrags diese Nummer wurde auf 22 reduziert. Diese Bemühungen wurden durch gedeckt 14 verschiedene Serien (nicht die verschiedenen Überarbeitungen zählen), herumbringen 76 neue Commits:

Unter allen verbleibenden Skripten sind möglicherweise nur wenige Kandidaten für eine direkte Konvertierung in den TEST_PROGS -Läufer. In der Tat gibt es mehrere Skripte, die nicht wirklich für die automatische Prüfung des EBPF -Subsystems konzipiert sind:

• Einige von ihnen testen die Kernel EBPF -Funktionen nicht wirklich, sondern externe Tools (zum Beispiel, zum Beispiel, bpftool)
• Einige andere entdecken Tests nicht wirklich, sondern einige Werkzeuge, die bereits vom test_progs Runner verwendet werden können
• Einige Skripte im Testverzeichnis sind wirklich dem Benchmarking gewidmet und sind daher für einen systematischen Lauf in CI nicht relevant

usw

Weitere Analysen und Diskussionen mit der Community müssen durchgeführt werden, um wirklich zu definieren, was mit diesen verbleibenden Skripten getan werden soll.

Eine relevantere Metrik ist die Anzahl der in Test_Progs integrierten neuen Tests:

• Auf Tag v6.11 lief eine beliebige Test_Progs -Ausführung (x86_64 mit GCC) 551 TestsLaichen 4103 Untertests
• Zum Zeitpunkt des Schreibens dieses Beitrags läuft dieselbe Testkonfiguration aus 606 Tests In CI, Laichen 4436 Untertests.

Diese Zahlen umfassen auch die neuen Tests, die andere Entwickler in dieser Zeitspanne beigetragen haben, aber sie spiegelt immer noch die Fortschritte bei den bisherigen Selbsttests wider. Es erhöht natürlich die Anzahl der EBPF -Funktionen, die durch die automatischen Tests abgedeckt sind, und gewährt mehr Vertrauen in alle im Subsystem zusammengefügten Code. Die Anstrengung ist noch nicht abgeschlossen, aber dank der Unterstützung der EBPF Foundation ist es definitiv in die richtige Richtung!

Wenn Sie diesen Beitrag genossen haben und neugieriger über unsere Arbeit an EBPF sind, sollten Sie unseren nächsten Beitrag in dieser Serie nicht verpassen, in dem wir in architekturspezifischere Funktionen und Details auf niedriger Ebene eintauchen!

Autor: Alexis Lothoré

Alexis arbeitet seit 2023 als eingebetteter Linux -Ingenieur bei Bootlin. Er hat vollständige Linux -Verteilungen für eine Vielzahl von Geräten verpackt, hauptsächlich für IoT -Geräte
Sehen Sie sich alle Beiträge von Alexis Lothoré an