İlk kernel katkım çalındı

• Yazar, PowerPC32 mimarisinde çalışan gdbserver ve çok iş parçacıklı uygulamalar içeren bir projedeki hata ayıklama sorununu ele alıyordu.
• Sorun, gdbserver bağlantısının kopması ve artık hata ayıklama oturumunun kontrol edilememesiydi.
• Araştırma ve inceleme sonrasında yazar, bu soruna yol açan tam commit'i işaret eden bir e-posta dizisi buldu.
• Yazar, PowerPC mimarisi ve task_struct çevresindeki değişikliklerle ilgili commit açıklamalarını okumak için 3-4 gün harcadı ve bu sorunun sonraki kernel sürümlerinde çözülüp çözülmediğini anlamaya çalıştı.
• Yazar, thread_struct iş parçacıklarını taşımak, pahole ile task_struct düzenini incelemek ve hata ayıklanan sürecin iş parçacıklarının ne zaman zamanlandığını anlamak için ftrace kullanmak gibi çeşitli araç ve tekniklerden yararlandı.
• Yazar, takılı kalan iş parçacığının diğerlerinden farklı olarak yalnızca bir kez zamanlandığını görerek, sorunun bir bellek bozulması problemi olabileceğini keşfetti.
• Yazar, Linux'ta donanım breakpoint'leri kullandı ve kimin yazdığını anlamak için __state alanına bir donanım breakpoint'i yerleştiren bir Linux kernel modülü geliştirdi.
• Yazar, sorunun ptrace_put_fpr içindeki bir buffer overflow'dan (POKEUSER API'si tarafından kullanılıyor) kaynaklandığını ve bunun task_struct içindeki __state gibi kritik alanların üzerine yazılmasına neden olduğunu keşfetti.
• Yazar, bunun bir güvenlik sorununa yol açabileceği için sorunu düzeltmek amacıyla Linux kernel güvenlik ekibine ([e-mail]) bir patch gönderdi.
• PowerPC yöneticisi Michael Ellerman, yazarın patch'ini kabul etmek yerine düzeltmenin kendi sürümünü uyguladı.
• Yazar, çalışmasının gerektiği gibi takdir edilmediğini, küçümsendiğini hissetti ve buna öfkelendi. Kendisine yalnızca Reported-by etiketi verildi.
• Yazarın ilk kernel katkısı, insanların kendi çalışmalarına uygun takdir verilmesini önemli görmemesi nedeniyle yaptığı konuşmalar boyunca hayal kırıklığı ve moral bozukluğuyla dolu bir deneyim oldu.

[GN⁺]

Hacker News görüşleri

• Katkı sahibinin yamasının tamamen kabul edilmemesine rağmen, bakımcının bu fikri kullanarak bir güvenlik sorununu çözdüğü duruma dair bir yazı
• Tam yama kabul edilmemiş olsa bile, bakımcının katkı sahibine kredi vermesi gerektiğini söyleyen bazı yorumlar
• Bakımcının yamasının daha iyi ve daha verimli olduğunu savunurken, katkı sahibinin sorunu tespit edip bir çözüm önerdiğinin de takdir edilmesi gerektiğini söyleyen başka görüşler
• Linux çekirdeğinin bir ödül olmadığı ve bakımcının en iyi çözümü seçme hakkı bulunduğunu söyleyen yorumlarla birlikte, katkı sahibine kredi vermenin önemini vurgulayan bazı yorumlar
• Yama fikrini öneren kişiye kredi vermenin bir yolu olarak çekirdek belgelerindeki "Suggested-by" etiketine değiniliyor
• Bunun çekirdeğe katkıda bulunmanın olağan bir parçası olduğu ve asıl amacın kredi almak değil hatayı düzeltmek olduğu yönünde bazı yorumlar
• Açık kaynak projelerde kendi katkılarının görmezden gelinmesi veya tamamen kabul edilmemesi deneyimlerini paylaşan yorumlar; bunun ek katkıları engelleyebileceği belirtiliyor
• Katkı sahibinin yaması ile bakımcının yamasını karşılaştıran, farklara dikkat çekip asıl yazara kredi verilmesi gerektiğini öne süren yorumlar
• Ayrıca genç ekip üyelerinin katkılarını, öğrenmeyi ve gelişimi teşvik edecek şekilde ele almanın önemine de değiniliyor
• Olumsuz tepki karşısında duyulan şaşkınlığı dile getiren yorumlar; takdirin önemli olduğunu ve ortak yazar eklemenin küçük ama anlamlı bir jest olduğunu savunuyor
• Tartışma, diplomasinin önemi ve açık kaynak projelerde uzun vadeli ilişkileri sürdürme gereği üzerine yorumlarla sona eriyor