"You break it, you fix it": Nvidia-Entwickler führt Linux-Bug bei AMD-GPUs ein - und behebt ihn selbst
Wer für den Bug sorgt, ist auch für die Reparatur zuständig - das gilt auch, wenn man als Nvidia-Entwickler ein Problem für AMD-Grafikkarten unter Linux produziert.
"You break it, you fix it": Das Prinzip bei Open-Source-Projekten, bei dem der Verursacher eines Bugs, für dessen Behebung zuständig ist, gilt auch unabhängig von der Firmenzugehörigkeit. Wie das Portal Phoronix berichtet, hatte ausgerechnet ein Nvidia-Entwickler einen Bug in einem Update auf Linux-Kernel 6.15 verursacht, der AMD-Grafikkarten betraf.
Die Änderung sollte eigentlich den adressierbaren PCI-Bar-Speicherbereich auf Systemen mit einer großen Menge an Arbeitsspeicher beheben. Hierbei kam es allerdings zu einer Fehlkonfiguration der Speichereinteilung, die sich beim Linux-Kernel unter anderem auf die DMA32-Zone für Geräte mit 32-Bit-Adressierung und die reguläre "Normal"-Zone aufteilt.
Durch die Änderung im Linux-Kernel aus der vergangenen Woche wurde der maximale adressierbare physische Speicher (max_pfn) fälschlicherweise auf 64 TiB gesetzt, was bei AMD-GPUs zur fehlerhaften Zuweisung in die DMA32-Zone führte. Daraus folgte eine direkte Auswirkung auf die Performance der AMD-Chips: Statt vollem Zugriff auf den Systemspeicher wurden diese auf den 4-GB-Bereich der DMA32-Zone beschränkt; zeitgleich reduzierte die Kernel-Änderung die "KASLR-Entropie", die für die Zufälligkeit (und damit die Sicherheit) der Speicheradressen beim Systemstart sorgt.
Der Fehler wurde kürzlich durch denselben Nvidia-Entwickler behoben, nachdem einige Rückmeldungen infolge der Kernel-Änderungen ein nicht näher beschriebenes Muster aufgewiesen hatten. AMD-Grafikkarten werden nun korrekt als Geräte mit voller 64-Bit-Adressierung erkannt, sodass es sich beim Fall weniger um Sabotage als um ein fantastisches Paradebeispiel für die Open-Source-Denkweise handelt.
zum thema direkt. ein nettes beispiel wie es gehen kann. feedback ist im foss bereich unabdingbar und reaktionen auf entsprechend konstruktives feedback folgen oft sehr schnell. das sieht und erlebt man auf github regelmäßig.
edit: hab den 6.15-rc1 mal kompiliert und getestet. aktuell keine probleme. läuft entgegen der annahme sehr gut.