İlk çekirdek katkım çalındı

 (ariel-miculas.github.io)
2 puan yazan GN⁺ 2023-09-28 | 1 yorum | WhatsApp'ta paylaş
  • Ariel Miculas, PowerPC32'de gdbserver çok iş parçacıklı hata ayıklamasının bozulduğu sorunu izlerken Linux çekirdeğinde bir bellek bozulması hatası buldu, ancak nihai düzeltme bakımcının ayrı bir yamasıyla alındı ve kendisi yalnızca Reported-by kredisi aldı
  • İpuçları, aynı belirtiyi ele alan eski bir posta dizisi ile task_struct içindeki thread_struct thread konumunu değiştiren commit'ten geldi; bazı iş parçacıkları yanlış süreç durumunda kalıyor ve bunun sonucunda gdbserver denetimi kaybediyordu
  • Kök neden analizinde pahole, ftrace ve PowerPC DABR tabanlı donanım kesme noktaları kullanıldı; ptrace_put_fpr içindeki tampon taşmasının task_struct.__state gibi alanların üzerine yazdığı doğrulandı
  • Taşma, 32 bit öğeler için olan bir indeksin 64 bitlik bir diziye uygulanmasından kaynaklandı ve kullanıcı tarafındaki gdbserver'ın yalnızca 32 öğelik fp_state.fpr dizisinin sonrasına en fazla 256 bayt yazabildiği bir durum oluştu
  • PowerPC bakımcısı Michael Ellerman kendi düzeltmesini uyguladı; daha sonra gönderdiği yanıtta, yalnızca Reported-by ile kredilendirmenin katkıyı düzgün yansıtmadığını ve yamayı birlikte geliştirmeleri gerektiğini söyleyerek özür diledi

PowerPC32'de bozulan gdbserver hata ayıklaması

  • Yaklaşık bir buçuk yıl önce Ariel Miculas, önceki şirketinde projenin hata ayıklama işlevini engelleyen bir sorunu araştırmak için zaman istedi
  • Sorun, PowerPC32 mimarisinde gdbserver'ın çok iş parçacıklı uygulamaları düzgün biçimde hata ayıklayamamasıydı
    • gdbserver bağlantısı kopuyor ve hata ayıklama oturumu artık kontrol edilemiyordu
    • Nedenin toolchain, gdbserver, Linux kernel ya da özel çekirdek yamalarından hangisinde olduğu net değildi
  • Mevcut araştırma ve aramaların ardından, aynı belirtiyi ele alan bir posta dizisi buldu
    • Bu dizi, soruna yol açan commit'i de işaret ediyordu
    • Söz konusu yama, task_struct ortasında bulunan thread_struct thread tanımını sona taşıyan bir değişiklikti

İş parçacığı durumundan bellek bozulmasına uzanan ipuçları

  • Holger Brunck'un önceki analizine göre gdbserver, her iş parçacığı için çekirdeğe SIGSTOP gönderip yanıt bekliyordu; ancak hatalı durumda çekirdek yalnızca bazı sinyallere yanıt veriyordu
  • Daha düşük seviyede, gdbserver ile etkileşimden sonra bazı iş parçacıkları yanlış süreç durumunda kalıyor ve gdbserver daha sonra denetimi kaybediyordu
  • Ariel, PowerPC ile ilgili commit açıklamalarını ve task_struct çevresindeki değişiklikleri 3-4 gün boyunca okuyarak sorunun sonraki çekirdek sürümlerinde çözülüp çözülmediğini kontrol etti, ancak bir çözüm bulamadı
  • thread_struct thread konumunu değiştirerek yeniden üretim koşullarını doğruladı ve pahole ile task_struct yerleşimini inceledi
  • ftrace ile hata ayıklanan sürecin iş parçacıklarının ne zaman zamanlandığını izledi
    • Durmuş iş parçacıkları, diğerlerinden farklı olarak yalnızca bir kez zamanlanıyordu
    • Bu gözlem, bellek bozulması olasılığına yeniden odaklanmasını sağladı

Donanım kesme noktalarıyla bulunan gerçek neden

  • x86'daki debug registers gibi, PowerPC'de de DABR register kullanılarak benzer bir işlev olduğunu doğruladı
  • Linux'ta donanım kesme noktalarının nasıl kullanılacağını araştırdıktan sonra, bir Stack Overflow yanıtını temel alarak bir çekirdek modülü geliştirdi
  • Bu modülle task_struct.__state alanına donanım kesme noktası koyup bu değeri kimin yazdığını izledi
  • Özel çekirdek modülü, task_struct.__state üzerine yazan konumun yığın izini gösterdi ve bunlar arasında şüpheli yol ptrace_put_fpr içindeki bir tampon taşmasına ulaştı
  • ptrace_put_fpr, POKEUSER API'sinde kullanılıyor ve taşma __state gibi task_struct içindeki kritik alanların üzerine yazıyordu
    • __state, süreç durumunu saklar
    • Çekirdek, hata ayıklayıcı tarafından durdurulan süreçleri izlerken de bu alanı kullanır

256 bayta kadar taşabilen dizi yazımı

  • Taşmanın nedeni, 32 bit öğeli bir diziye yazmak için tasarlanmış indeksin 64 bit öğeli bir diziye uygulanmasıydı
  • FPR'yi gösteren indeks 64'tü ve 64 bit öğe temelinde erişim aralığı 64 * 8 = 512 bayttı
  • Gerçekte fp_state.fpr dizisinde yalnızca 32 giriş vardı ve kullanılabilir bellek 32 * 8 = 256 bayttı
  • Sonuç olarak kullanıcı, yani gdbserver, dizinin sonunu aşarak en fazla 256 bayt yazabiliyordu

Upstream gönderim ve kredi anlaşmazlığı

  • Ariel, süreç durumu belleğinin üzerine yazılabilen bu bellek bozulması sorununun güvenlik etkileri olabileceğini düşünerek yamayı security@kernel.org adresine gönderdi
    • Bu posta listesi özel olduğu için ilk gönderdiği yama bağlantılanamıyordu
  • PowerPC bakımcısı Michael Ellerman özel olarak iletişime geçip konuyla ilgileneceğini söyledi
  • Ariel iki düzeltme yaması gönderdi
  • İkinci yama, PowerPC64 üzerinde PowerPC32 davranışını öyküleyen mevcut çekirdek koduna dayanıyordu ve bu kod FPR indekslemeyi doğru biçimde ele alıyordu
  • Michael Ellerman iki yamayı da kabul etmedi ve kendi düzeltmesini uyguladı
  • Ariel, bu sorunu düzeltme başarısı ve ilk çekirdek katkısı için kredi alabilmek adına kendi yamasının kabul edilmesini istiyordu; geri bildirimi yansıtıp yeni sürümler göndermeye de istekliydi
  • Fakat fiilen aldığı kredi yalnızca Reported-by etiketi oldu ve Ariel, kök neden analizi, düzeltme, test, doğrulama, şirket içi geri bildirimleri yansıtma ve güncel çekirdeğe uygulama için harcadığı çabaya kıyasla bunun adil olmadığını düşündü
    • Linux belgelerine göre Reported-by, hatayı bulan ve bildiren kişiye kredi veren etikettir
    • Bu sorun aslında 6 yıl önce zaten bildirilmişti

Güncelleme ve özür yanıtı

  • Bir Hacker News kullanıcısı, Michael Ellerman'ın “Yama için teşekkürler ama bunu farklı şekilde düzeltmek istiyorum. Aşağıdaki yamayı test edip hatanın düzelip düzelmediğini doğrulayabilir misin?” dediği e-postaya dikkat çekti
  • Bu e-posta, Michael Ellerman'ın Ariel'in yamasını gözden geçirmek yerine kendi uygulamasını seçtiğini ve Ariel'den bu yamayı test etmesini istediğini gösteriyordu
  • Ariel, güvenlik posta listesine gönderdiği ilk yamayı bulup linuxppc-dev'e posta dizisini iletti
  • Daha sonraki güncellemede, yamaların ele alınış biçimi için gönderilmiş bir özür yanıtı da yer aldı
    • “Yamanı birlikte geliştirmek için daha fazla zaman harcamalıydım” ifadesi buna dahildi
    • Reported-by etiketinin Ariel'in katkısını yeterince yansıtmadığı da belirtildi

İlgili okumalar

1 yorum

 
GN⁺ 2023-09-28
Hacker News yorumları

  • Tüm yamayı kabul etmeyecek olsalar bile Ariel Miculas'a katkı payı vermek daha uygun olurdu.
    Bu güvenlik sorununu o bulup bir düzeltme göndermeseydi, büyük olasılıkla kimse düzeltmeyecekti.
    Michael onun yamasını okuyup yalnızca stilini biraz değiştirerek kendi adıyla gönderdiyse, katkı payı vermemek etik dışı olur; kod çok kötü olsa bile bu yine de bir iş birliğiydi, böyle bir şeye maruz kalsam tekrar birlikte çalışmak istemezdim.

    • Eskiden başkasının katkısını alıp kendi branch'imde tamamen yeniden yazarak merge etmenin ya da GitHub PR'ına yeni commit olarak yeniden yazıp koymanın sorun olmadığını düşünürdüm.
      İkincisinde yine de Co-Authored-By kalıyor; ama biri benim proje kodumu commit geçmişi olmadan kendi deposuna dump edip “fork”ladıktan sonra, katkıda bulunan kişi açısından bunun epey buruk bir deneyim olduğunu fark ettim.
      Kod kötü olsa bile, merge edilen refactor edilmiş düzeltme o kod olmadan var olmayacaktı ve “benim sürümüm daha iyi” demek oldukça küçümseyici hissedilebilir.
      Ancak bakımcının gerçek yanıtını linkleyen cevaba bakınca son cümle geçerli değil.
    • Katılıyorum. Bakımcı, kalite nedeniyle çekirdeğe girecek kodu kendisinin yazacağını söyleyebilir ve bu başlı başına anlaşılır.
      Ama bu durumda yazı sahibi, o yamanın ortak yazarına daha yakın.
      Akademik yayıncılık açısından bakarsak, birine preprint gönderiyorsunuz; o kişi aynı konuda makale yayımlarken sizi yalnızca teşekkür bölümüne koyuyor, ortak yazar yapmıyor. Buna benziyor.
      Burada yayın değil çekirdek geliştirme söz konusu, ama yazar gösterimi profesyonel özgeçmişte hâlâ önemli.
    • Deneyimli bir bakımcının rolünü, başkalarının katkılarının temiz biçimde içeri girmesine elinden geldiğince yardımcı olan bir kolaylaştırıcı olarak görüyorum.
      Stil ve yapı tutarlılığı hakkında geri bildirim gerekli; ama iyi bir bakımcı, emeği teslim eden ve işlerin arka planda sorunsuz akmasını sağlayan kişidir.
    • Linux çekirdeğine ilk birkaç yamamı gönderdiğimde, LKML üzerinden yarı otomatik gönderim bile mümkün olmadan önceydi; bakımcıyla konuşarak ilerlemiştim.
      O zaman Ted Tso çalışmamın doğruluğundan memnun kalınca yamayı aldı; ben de ne katkı payı istedim ne de aldım.
      Benim ilgim yalnızca çekirdeği iyileştirmekti, adımı bırakmakla ilgilenmiyordum.
      Birkaç yıl sonra başka bir iş nedeniyle katkıcı listesine adım girdi, ama her iki durumda da umursamadım.
    • O katkı payını aldı. Commit'te Reported-by: Ariel Miculas yazıyor ve doğru görünüyor.

  • Bakımcının yaması daha iyi.

    1. 32 bit durumunda fpidx < (PT_FPSCR - PT_FPR0) kontrolünü kaybetmiyor.
    2. put fonksiyonunda fpidx aralık dışına çıktığında kullanılan *data = child->thread.fp_state.fpscr; yedek atamasını kaybetmiyor.
    3. TS_FPRWIDTH 1 ise özdeşliğe indirgenen gereksiz FPRINDEX makrosundan kaçınıyor.
      Orijinal yama commit mesajı “PPC32'de TS_FPRWIDTH'in 1 olduğu varsayılabilir” dediği hâlde FPRNUMBER, FPRHALF, FPRINDEX içeriyordu.
      Basitçe düzeltilebilir bir dizi uyumsuzluğu buldu diye hatalı bir yamayı olduğu gibi kabul etmek gerekmiyor.
      Ancak bakımcının, Miculas'ın yalnızca bildirim yapmakla kalmayıp araştırarak kök nedeni bulduğunu ve neredeyse aynı basit düzeltmenin kendi sürümünü de oluşturduğunu kabul etmesi gerekirdi.
      Reported-by, ilgili kişinin kapsamlı araştırma yapıp nedeni de ortaya koyduğu nüansını taşımak için isabetli değil.
    • Bakımcının işinin daha iyi olduğuna katılıyorum. Ama yama için basitçe kod incelemesi yapıp güncelleme isteyebilirdi.
      Yeni katkıcılar için projelerde genellikle böyle yapılır ve doğru yöntem budur.
      Bu, insanları öğretme ve uyumlandırma sürecidir; işi öylece yeniden yaparsanız katkı motivasyonunu kırar ve öğrenme fırsatını da ortadan kaldırırsınız.
    • Hata ayıklama zordur, bazen çok zordur. Aşina olunan bir kod tabanında düzeltme yazmak nispeten önemsiz bir iştir; özellikle de önceki düzeltmenin çalışan bir sürümü rehber olarak varsa daha da kolaydır.
      İkinci sürümü yazmak her zaman daha kolaydır.
      Buna basit bir düzeltme demek, yazılım geliştirmede hata düzeltmeye giren iş miktarını anlamamaktır.
      Burada Michael da başlangıçta yeniden üretemediğini, ancak daha sonra doğruladığını kabul etmişti.
      Bu, OP'nin hata ayıklama ve düzeltme için harcadığı emeği iyi gösteriyor; o emeği elinden almak doğru değil.
    • “Basitçe düzeltilebilir bir dizi uyumsuzluğu buldu diye hatalı bir yamayı olduğu gibi kabul etmek gerekmiyor” demek, başkasının sözünü çarpıtmak oluyor.
      Asıl metinde yamalarının kabul edilip katkı payı almak ve çekirdek katkıcısı olmak istediğini, geri bildirimi yansıtıp sonraki sürümü de göndermeye istekli olduğunu söylemişti.
    • Kimse orijinal yamanın olduğu gibi kabul edilmesi gerektiğini söylemiyor.
      Bakımcı, OP'nin kodunu checkout edip istediği değişiklikleri yaptıktan sonra ortak yazar olarak commit etmek için gereken yaklaşık 2 dakikayı harcayabilirdi.
      Böylece en iyi düzeltme merge edilir ve başkasının emeği de tanınmış olurdu.
      Özellikle OP katkısının tanınmasını istediğini açıkça ifade ettiği için en iyi yol buydu.
      Yine de bu tür depo bakımcılarının sosyal nezaketi sık sık kaçırıyor olması şaşırtıcı değil.
    • Birçok açık kaynak projeye sayısız yama ve PR gönderdim; çoğunun amacı kendi sıkıntımı çözmekti.
      PR'lar birçok nedenle çoğu zaman kabul edilmez, ama umursamam.
      Kodu açıkta tutmak için PR gönderiyorum; merge edilecek kadar “iyi” hâle getirmek için zaman harcamıyorum.
      Olduğu gibi sunuyorum; biri yeterince beğenirse süreci o halleder.
      Bazıları olduğu gibi merge edildi, bazılarını depo sahibi biraz düzelterek merge etti.
      Açık kaynak kodu şan ya da popülerlik için değil, sevdiğim için yazıyorum.
      80'leri ve 90'ları özlüyorum.

  • Linux çekirdeği bir ödül değildir; OP’ye empati duysam da topluluğun sunduğu sürümden ziyade bakımı daha kolay bir çözümü tercih etmek doğrudur.
    Bu yüzden bakımcı yetki alanı içinde hareket etmişti.
    Yine de düzeltmeye katkıda bulunan kişiye emeğini belirtmek çok kolaydır.
    Node.js’te sürüm notlarında emeği belirtiriz; bir PR’daki çalışmanın bir kısmını alıp değiştirdiğimizde de Co-Authored-By: eklemeye çalışırız.
    Uzun süre bakımcılık yapınca emeğin belirtilmesi sizin için daha az önemli hâle gelebilir; bu yüzden yeni katkıda bulunanlar için bunun çok önemli olduğunu unutmak kolaydır.
    Bu vakada olduğu gibi emeğin paylaşılması OP için önemliydi ve hak edilmişti; bu konuda daha özenli olunmaması hem OP hem de Linux’un ilgili alanı için bir kayıptır.

    • Bir projeye çok emek verip katkınızı düzelttikten sonra sonunda “benim sürümüm daha iyi, hadi git” denirse insan sinirlenir.
      Topluluk emeğine dayanan bir projenin sürdürülebilir yolu bu değildir.
      Linux çekirdeği kadar büyük ve saygı duyulan bir projede hem projenin en iyisini gözetebilen hem de yeni katkıda bulunanlara saygı gösterebilen insanlar olduğunu düşünürdüm.
      Kimse sırf yeni katkıda bulunan biri diye en iyi olmayan bir çözümü kabul edelim demeyecektir.
      Doğru yol yamayı incelemek, neyin neden sorun olduğunu açıklamak, nasıl yeniden yazılmasının iyi olacağını önermek ve gerekirse o kısmı birlikte yazarak ortak yazar olmaktır.
      Ancak böylece gelecekte de ilgi duyan katkıcıların akışı oluşur.
    • “Linux çekirdeği bir ödül değildir” sözü, bu yazıya bakınca en kötü anlamıyla doğru görünüyor.
    • Görünüşe göre kendisine Reported-By etiketiyle kredi verilmiş.

  • Çekirdek belgelerinde etiket teamüllerinden biri olarak Suggested-by tanımlanmış.
    Suggested-by: etiketi, yama fikrinin o kişi tarafından önerildiğini gösterir ve o fikrin emeğinin belirtilmesini güvence altına alır.
    Özellikle fikir herkese açık bir forumda yayımlanmadıysa, öneren kişinin izni olmadan eklenmemesi gerektiği belirtiliyor.
    Fikri bildiren kişilere dürüstçe kredi verilirse, ileride tekrar yardımcı olma olasılıklarının artacağı da yazıyor.
    Bu durumda Suggested-by daha uygun olabilirdi.
    Sorunun çözümünü bulduğunu, ancak projeye aşina olmadığı için yamanın tam söz diziminin korunmadığını daha iyi ifade ederdi.
    Referans: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

    • Yamaları karşılaştırmadım ama aşağıdaki yoruma [1] göre kabul edilen yama ile önerilen yama arasındaki tek fark düzeltmenin konumuymuş.
      Birinde if dışındaki ifdef içinde, diğerinde ise içteki if ifadesinde yer alması dışında bir fark yok; bunun teknik bir fark değil, stil farkı olduğu söyleniyor.
      Eğer öyleyse yazar, yalnızca yama fikrini “önermekten” çok daha fazlasını yapmış.
      Sorunu debug etmiş ve tüm yamayı yazmış; küçük bir değişiklikle kabul edilmiş sayılır.
      1: https://news.ycombinator.com/item?id=37672558
    • Bu yöntem de mümkün, ama güvenlik sorunu olmayan durumlara daha iyi uyuyor gibi.
      Güvenlik sorunlarında hız ve doğruluk biçimden daha önemlidir; çekirdek bakımcıları Reported-by ile kredi vererek doğru şekilde hareket etmiş.
      Suggested-by biraz daha iyi olurdu ama OP’nin istediği bu değil; OP çok küçük bir yamaya dayanarak “çekirdek katkıcısı” etiketi istiyor gibi görünüyor.

  • Bu başlıktaki bazı tepkilere bakınca, bazı kişilerin özellikle junior ya da orta seviye geliştiricileri yönetmemesini umuyorum.
    Ekibinizde hevesli bir junior varsa ve bir soruna yardımcı olan ama kalitesi yetersiz bir PR açtıysa, “yeterince iyi değil” diye azarlayıp kodu çöpe attıktan sonra kendiniz yeniden yazmak verilebilecek en kötü tepkidir.
    Morali bozar, hem onun hem kendi zamanınızı boşa harcar, hiçbir şey öğrenmesini engeller; bir dahaki sefere iyileştirme yapmasını ya da anlamlı katkıda bulunmasını zorlaştırır, yardım istemekten veya gönüllü katkı vermekten de soğutur.
    Karmaşık bir kod alanına dalmış olsa bile, daha iyi etkileşim yolları vardır.

    • Bir şirkette ya da ekipte junior’ları yönetip koçluk yapmak ile internette rastgele bir kişinin küçük bir yama göndermesi farklı şeylerdir.
      Ekipteki junior’ın bir süre kalacağı beklentisi vardır; mülakatla temel yetkinlikleri de bir ölçüde doğrulanmıştır, bu yüzden gelişme potansiyeline güvenebilirsiniz.
      İnternetteki rastgele bir kişinin kalma yükümlülüğü yoktur ve bu tür “drive-by” düzeltmelerin çoğu kalıcı olmaz.
      O kişinin gerçekte ne becerilere sahip olduğunu, düzeltme taleplerine nasıl tepki vereceğini de bilmezsiniz.
      Yönetim açısından en sinir bozucu şeylerden biri, birinin rastgele bir kişiyi benim raporlama hattıma koyup onun performansından beni sorumlu kılmasıdır.
      Şimdi internette hak sahibi tavırlar içindeki birinin birkaç gününü harcayıp düşük seviyeli bir düzeltme yaptığını ve benim de onun yöneticisiymişim gibi koçluk yapmam gerektiğini hayal edersek, bu benzetme hiç tutmuyor.
      Eskiden GitHub’da proje barındırınca istenmeyen PR’lar yüzünden neden bu kadar yaygara koptuğunu merak ederdim; artık anlıyorum.
      Rastgele PR’larla uğraşmak istemediğinizde “morali bozan, zamanını boşa harcatan kötü yönetici” diye suçlanmanız aşırı bir hak sahipliği duygusu.
      Örnek: https://news.ycombinator.com/item?id=25940799
    • Aşırı istekli bir junior, öncelik olmayan ve kendisine verilmemiş bir işi bir hafta boyunca çözmeye uğraştıysa, onu kenara çekip “Bunu şimdilik beklemeye alalım, sonra tekrar bakarız. Şu anda öncelik X, bu yüzden buna zaman ayıramayız” diyebilirsiniz.
      Profesyonel olmak, kendinizi yaptığınız işten ayırmayı ve iş arkadaşınızın sizi baltalamak için kötü niyetli bir plan içinde olmadığını öğrenmeyi de içerir.
      Herkesin aylarca çalıştığı bir projenin iptal edildiği, kod incelemesinde sert yorumlar aldığı olmuştur.
      Bunları kabul edip öğrenmek profesyonel olmanın bir parçasıdır.
      Elbette doğrudan ve kaba insanlar da bu tavrın birçok ilişkiyi bozduğunu öğrenmelidir.
      Biz sanatçı değil, profesyoneliz.
      Junior bir inşaat mühendisi yapısal kusuru olan bir köprü tasarlasa ve kıdemli kişi “Üzgünüm ama bunu artık kurtarmak zor, her şeyi baştan yapmam gerekecek” dese, kıdemlinin yaptığı sorunlu olmaz.
      Junior’ın gururunu korumak için güvensiz bir köprüden geçmek istemem.
      Büyük açık kaynak projeleri sürdürme deneyimi pek olmayan yorumlar, bakımcıyı özellikle sert görüyormuş gibi.
      Küçük bir açık kaynak projeyi sürdürünce, rastgele birinin PR’ını kabul etmenin çok iş olduğunu ve çoğu zaman kendiniz yapmaktan daha fazla zaman aldığını görürsünüz.
      Kodu dikkatle incelemek, katkıda bulunan kişiyle iletişim kurup sorunları düzeltmek, beklenen kalite ve teamüllere uydurmak çok zaman alır.
      İş yerindeki junior zaten mülakattan geçmiştir; burada ise rastgele bir yabancı değişiklik istiyor.
      PR reddedilince üzülmek normal, ama iki tarafın bakış açısını da anlıyorum.
      Bakımcının konuşmalarına bakınca özellikle kötü niyetli ya da kaba görünmüyor.
    • Tekrar okumanız iyi olur. Gerçekten böyle bir şey yaşanmış gibi görünmüyor; en azından taraflardan birinin duygusal bir yeniden kurgusu olma ihtimali var.
    • Bu başlıkta gerçekten hayal kırıklığı yaratacak kadar çok sert yorum var.
      Neredeyse LKML’nin kötü başlıklarından biri gibi hissettiriyor.
      O kişi kelimenin tam anlamıyla işin %95’ini yapmış, ama emeğinin tanınmasını istediği için eleştiriliyor.
      Bunun neden yapıldığını hiç anlamıyorum.
    • Bu başlık kötü kişilerarası ilişkileri ortaya çıkaran bir paratoner gibi; HN okur kitlesinin yaş aralığını düşününce epey utanç verici.

  • İki yamayı karşılaştırınca belirgin bir fark görülüyor.
    Bağlantısı verilen yazıdaki katkı if...else ifadesinin iki dalındaki davranışı da değiştiriyor; nihai katkı ise yalnızca if dalı içindeki yolu değiştiriyor.
    Bakımcının kodu değiştirmesinin bir nedeni olmalı.
    Yine de gerçek düzeltme neredeyse %100 kopyalandığı için, özgün yama yazarına emeğinin karşılığını vermek uygun olurdu.

    • Yukarıdaki e-posta konuşmasındaki özgün yama için de aynısı geçerli.
      Özgün sonuçta PPC32 mimarisinde flush_fp_to_thread de yok, else koşulu da yok.
      Nihai yama flush_fp_to_thread(child); çağırıyor, fpidx aralık kontrolü içinde CONFIG_PPC32 olup olmamasına göre işlem yapıyor, aralık dışındaysa fpscr atıyor.
      Bu yüzden iki çözüm arasında gerçek bir fark var.
      Hangisinin doğru ya da daha iyi olduğunu söyleyemem, ama sonuçların farklı olduğu kesin.
    • Uzun süredir C kullanan biri olarak, özel makrolarla dolu bir kod geldiğinde temkinli olurdum.
      Bu, C konusundaki acemiliğe işaret ediyor olabilir.
      Büyük kod tabanı bakımı yarı yarıya yangın söndürmek, yarı yarıya da isim çakışmalarından kaçınmaktır.
    • Yazının yazarıyım. Ne yazık ki gönderdiğim özgün yamayı yalnızca Linux kernel güvenlik e-posta listesine gönderdiğim için link veremiyorum.
      O yama epey farklıydı; keşke gösterebilmek için bir yere kaydetseydim.

  • Bu, kernel katkılarının olağan bir parçası
    Sorunu en kısa ve net şekilde aktarmanın yolu çoğu zaman bir patch olduğu için patch gönderilir; beklenti de onların o patch’i kullanmayacağı yönünde olmalı
    Aklıma gelenlerden bile bunun bana en az üç kez [1][2][3] olduğunu hatırlıyorum
    Açıkçası buna kızmayı hiç düşünmedim; çünkü asıl hedefim bug’ı düzeltmekti ve bunun gerçekleşmesine sevindim
    OP’ye içten tavsiyem, bu blog yazısını silmesi olur. İleride pişman olacak
    [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
    [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
    [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

    • Karşı tarafın adını açıkça verip onu otobüsün altına atmak gerçekten kötü görünüyor
      Diğer kişinin adını görünce epey şaşırdım

  • Açık kaynak projelerde bu sürekli oluyor ve sonuçta insanın daha fazla katkı yapma isteğini kırıyor
    Geçen yıl yıllardır açık duran bir issue’yu üstlendim, PR hazırladım, test kodlarını da düzelttim; ayrıca build sorununu düzelten ayrı bir iş de yaptım
    Bakımcı yalnızca build sorununu düzelten PR’ı aldı, asıl issue’yu ise düpedüz görmezden geldi
    O projeye yeniden zaman ayırıp katkıda bulunma ihtimalim kesinlikle yok

    • Bazı insanların GitHub özgeçmişi tamamen kopyala-yapıştır katkılardan oluşuyor
      PR açıyorsun, değişiklik isteyen yorumlar alıyorsun
      Birkaç gün sonra vakit bulup düzeltmeye çalıştığında, düzenli katkı yapan birinin açtığı başka bir PR ile çoktan kapatılmış oluyor
      O PR’a bakınca kodunun neredeyse aynısı olduğunu, sadece bir değişken adının değiştiğini ve “arkadaş” review standardıyla hemen onaylandığını görüyorsun
      O kişinin profiline bakınca katkılarının neredeyse tamamının başkalarının kodunu kopyalamaktan ibaret olduğu görülüyor
    • Küçük bir projenin bakımcısı olarak insanların kod ya da test katkısı yapmasını isterim
      Kod tabanının geri kalanına uyacak şekilde toparlamalarına yardımcı olmaya çalışıyorum; en zor kısım da bu
      Çünkü çoğu geliştirici önce proje geleneklerini öğrenmek yerine, düzelttiği şeyi doğrudan içeri sokmak istiyor
      Yine de kod kabaca doğruysa ve merge’den sonra benim 15 dakika kadar rötuş yapıp biraz daha test eklemem yeterli olacaksa kabul ediyorum
      Bu vakada da durum buna benziyor; bakımcı böyle yapmalıydı
      Katkı sahibi emeğinin karşılığını alır, bakımcı da upstream’e kabul edilecek hale gelmesi için gereken temizliği birkaç dakikada yapar ve herkes mutlu olurdu
      “Benim sürümüm daha iyi” demek, gerçekten daha iyi olsun ya da olmasın, çok kibirli ve profesyonellik dışı
      Issue ilk bildirildikten sonra 6 yıl boyunca düzeltemediysen, o kişinin katkısı olmasaydı senin düzeltmenin de olmayacağını kabul etmelisin
      “Çözümü” gördükten sonra o düzeltmeyi almak fiilen hırsızlığa yakın
    • Benim deneyimime göre kod projelerinin istediği katkı bug raporları ve iyileştirme fikirleridir; ille de senin kodun değil
      İnsanlar kodları kabul edilmeyince ya da yeniden yazılınca bunu kişisel algılıyor, ama bir projeyi yürütürken kod yazmanın işin küçük bir kısmı olduğunu kaçırıyorlar
    • Yaygın bir sorun
      Ben genelde bug raporlarına ve merge request’lere bakıp patch’in nasıl ele alınacağını kestirmeye çalışırım
      Katkı yapmaya uygun görünmeyen projelerde pek çok bug düzeltmesinden vazgeçtim; 2003’teki Linux kernel de buna bir örnekti
      Bazı projeler zaten böyle; bulaşmamak daha iyi ve çoğu zaman zaman kaybı oluyor
      Artık yapay zeka devriminden sonra açık kaynak lisansları geniş çapta ihlal edildiği için, o zamandan beri açık kaynak kod göndermedim ve bundan sonra da göndermeyeceğim

  • Buradaki toksikliği gerçekten anlamakta zorlanıyorum
    “Bunu takdir, yıldız, ödül, özgeçmiş gibi şeyler için yapmamalısın” türü sözler kulağa delice geliyor
    Bunu söyleyen insanların işi var mı? Varsa tutarlı olmak için tamamen ücretsiz çalışmaları gerekir
    Maaş da katkı için bir takdir biçimidir
    Şahsen nihai çözüm önerilenden farklılaşmış olsa bile, asıl çözümün keşfine dayanıyorsa ortak yazar eklemek çok küçük bir şey
    Yazarın bu konuda şikâyet etmek için geçerli nedeni var; birinin katkısının takdir edilmediğini hissetmesi de ne ilk ne son olacak

    • İnsanlar, iyi yaptığımız işler için hiçbir takdir istemeyen kod robotlarıymışız gibi davranıyor
      Patch’in kendisi daha zayıf olsa bile, debugging emeği kesinlikle öyle değildi
    • Bu, istihdam ilişkisinden farklı bir durum
      İstihdamda işveren ile çalışan, bir karşılık uğruna iş yapılacağı konusunda anlaşır
      Haber vermeden bir şirkete girip kimsenin istemediği bir işi yapmaya başlasan, çok az kişi karşılık alma hakkın olduğunu savunur
      OP’nin başına gelenlere daha doğru benzetme bu
    • Asıl yazarı takdir edip kendini editör olarak sunmak daha adil olurdu

  • “Kusura bakma ama benim sürümüm daha iyi. Linux kernel katkıcısı olmak istiyorsan burada düzeltebileceğin bir issue var” tarzı bir yanıt, birinin bir daha yardım etmemesini sağlamak ve başkalarının da hevesini kırmak için harika bir yöntemdir

    • Asıl ifade farklıydı
      Bakımcı, gdbserver ile çöküşü yeniden üretemediğini, ancak hatayı gösteren bir test case olduğu için bunu doğrulayıp düzeltmeyi test ettiğini söyledi ve “Patch için teşekkürler ama bunu farklı şekilde düzeltmek istedim. Aşağıdaki patch’i deneyip hatanın düzelip düzelmediğini kontrol edebilir misin?” diye yazdı
      https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...
      Ayrıca bahsedilmeyen başka review yorumları da vardı
      Yalnızca PPC32 için olan makronun ne gibi bir faydası olduğunu bilmediği, #ifdef’den mümkün olduğunca kaçınılması gerektiği ve Michael’ın patch’inin daha anlaşılır olduğu yönündeydi
      https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...
    • Bakımcı aslında bunu söylemedi
      OP, karşı tarafın ağzına laf koyup buna kızıyor; özellikle metin tabanlı iletişimde bu iyi bir strateji değil
    • Özellikle OP, bu issue’nun 6 yıl önce raporlandıktan sonra görmezden gelindiğini yazmışken, bakımcının davranışı epey kötü
    • Gerçekte hiç de böyle olmadı
      OP konuşmayı kaba geçmiş gibi göstermeye çalışıyor, ama aslında öyle değildi
    • Üstelik bakımcının bir dahaki sefere yine “benim sürümüm daha iyi” deyip başka bir bug’ı işaret etmeyeceğinin garantisi nerede?