Mein erster Kernel-Beitrag wurde gestohlen

• Der Autor bearbeitete ein Debugging-Problem in einem Projekt mit gdbserver, das auf der PowerPC32-Architektur lief und eine Multi-Thread-Anwendung umfasste.
• Das Problem bestand darin, dass die Verbindung zu gdbserver abbrach und die Debug-Session dadurch nicht mehr steuerbar war.
• Nach Recherche und Untersuchung fand der Autor einen E-Mail-Thread, der auf den exakten Commit verwies, der dieses Problem verursacht hatte.
• Der Autor verbrachte 3–4 Tage damit, Commit-Beschreibungen zu Änderungen rund um die PowerPC-Architektur und task_struct zu lesen, und versuchte herauszufinden, ob das Problem in späteren Kernel-Versionen behoben worden war.
• Der Autor nutzte verschiedene Werkzeuge und Techniken, darunter das Verschieben von thread_struct-Threads, die Inspektion des Layouts von task_struct mit pahole sowie den Einsatz von ftrace, um festzustellen, wann Threads des debuggten Prozesses eingeplant wurden.
• Der Autor stellte fest, dass es sich um ein Problem mit Speicherbeschädigung handeln könnte, da der festhängende Thread im Gegensatz zu anderen Threads nur einmal eingeplant wurde.
• Der Autor verwendete Hardware-Breakpoints unter Linux und implementierte ein Linux-Kernel-Modul, das einen Hardware-Breakpoint auf das Feld __state setzte, um herauszufinden, wer darauf schrieb.
• Der Autor entdeckte, dass das Problem durch einen Buffer Overflow in ptrace_put_fpr verursacht wurde (verwendet von der POKEUSER-API), wodurch wichtige Felder von task_struct wie __state überschrieben wurden.
• Da dies zu einem Sicherheitsproblem führen konnte, schickte der Autor einen Patch an das Linux-Kernel-Sicherheitsteam ([e-mail]), um das Problem zu beheben.
• Der PowerPC-Maintainer Michael Ellerman implementierte jedoch statt der Übernahme des Patches des Autors seine eigene Version der Korrektur.
• Der Autor war verärgert und hatte das Gefühl, seine Arbeit werde nicht angemessen gewürdigt und er werde unterschätzt. Er erhielt lediglich ein Reported-by-Tag.
• Der erste Kernel-Beitrag des Autors war eine frustrierende und entmutigende Erfahrung voller Gespräche mit Menschen, die es offenbar nicht für wichtig halten, dass andere für ihre Arbeit angemessen anerkannt werden.

[GN⁺]

Hacker-News-Kommentare

• Ein Artikel über eine Situation, in der der Patch des Beitragenden nicht vollständig übernommen wurde, der Maintainer aber die Idee nutzte, um ein Sicherheitsproblem zu beheben
• Einige Kommentare meinen, dass der Maintainer dem Beitragenden Anerkennung hätte geben sollen, auch wenn der vollständige Patch nicht übernommen wurde
• Andere argumentieren, dass der Patch des Maintainers besser und effizienter sei, zugleich aber anerkannt werden müsse, dass der Beitragende das Problem erkannt und eine Lösung vorgeschlagen hat
• Einige Kommentare betonen, dass der Linux-Kernel keine Belohnung sei und der Maintainer das Recht habe, die beste Lösung zu wählen, heben aber zugleich die Bedeutung hervor, dem Beitragenden Anerkennung zu geben
• Erwähnung des Suggested-by-Tags in der Kernel-Dokumentation als Möglichkeit, der Person Anerkennung zu geben, die die Patch-Idee vorgeschlagen hat
• Einige Kommentare sagen, dass dies ein normaler Teil der Arbeit am Kernel sei und das Hauptziel darin bestehe, Bugs zu beheben, nicht Anerkennung zu erhalten
• Kommentare teilen Erfahrungen aus Open-Source-Projekten, in denen eigene Beiträge ignoriert oder nicht vollständig übernommen wurden, was weitere Beiträge behindern kann
• Kommentare vergleichen den Patch des Beitragenden mit dem des Maintainers, weisen auf Unterschiede hin und schlagen vor, dass dem ursprünglichen Autor Anerkennung hätte gegeben werden sollen
• Die Diskussion streift auch die Bedeutung, mit Beiträgen jüngerer Teammitglieder so umzugehen, dass Lernen und Verbesserung gefördert werden
• Ein Kommentar drückt Verwirrung über die negativen Reaktionen aus und argumentiert, dass Anerkennung wichtig sei und das Hinzufügen eines Co-Autors eine kleine, aber bedeutungsvolle Geste sei
• Die Diskussion endet mit Kommentaren über die Bedeutung von Diplomatie und den Erhalt langfristiger Beziehungen in Open-Source-Projekten