मेरा पहला kernel contribution चोरी हो गया

 (ariel-miculas.github.io)
2 पॉइंट द्वारा GN⁺ 2023-09-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Ariel Miculas ने PowerPC32 पर gdbserver multithreaded debugging के टूटने की समस्या को ट्रैक करते हुए Linux kernel में memory corruption bug पाया, लेकिन अंतिम fix maintainer के अलग patch के रूप में गया और उन्हें सिर्फ Reported-by credit मिला
  • सुराग वही symptoms संभालने वाली पुरानी mail thread और task_struct के अंदर thread_struct thread की position बदलने वाला commit था, जिससे कुछ threads गलत process state में फंसे रहे और gdbserver ने control खो दिया
  • root cause analysis में pahole, ftrace, और PowerPC DABR-based hardware breakpoint का उपयोग हुआ, और यह confirm हुआ कि ptrace_put_fpr का buffer overflow task_struct.__state जैसे fields को overwrite कर रहा था
  • overflow इसलिए हुआ क्योंकि 32-bit elements के लिए बने index को 64-bit array पर apply किया गया, और सिर्फ 32 items वाले fp_state.fpr array के बाद user-side gdbserver अधिकतम 256 bytes तक लिख सकता था
  • PowerPC maintainer Michael Ellerman ने अपना fix apply किया; बाद की reply में apology थी कि सिर्फ Reported-by Ariel के contribution को ठीक से reflect नहीं करता और patch को साथ मिलकर आगे develop करना चाहिए था

PowerPC32 पर टूटी हुई gdbserver debugging

  • करीब डेढ़ साल पहले, Ariel Miculas ने अपनी पिछली company में project की debugging functionality को block कर रही problem investigate करने के लिए time मांगा
  • problem यह थी कि PowerPC32 architecture पर gdbserver multithreaded application को ठीक से debug नहीं कर पा रहा था
    • gdbserver connection टूट जाता था और debug session पर आगे control नहीं रहता था
    • यह clear नहीं था कि cause toolchain, gdbserver, Linux kernel, या custom kernel patches में कहां है
  • existing investigation और search के बाद उसी symptom पर चर्चा करने वाली mail thread मिली
    • यह thread problem पैदा करने वाले commit की ओर भी इशारा करती थी
    • वह patch task_struct के बीच में मौजूद thread_struct thread definition को अंत में move करने वाला change था

Thread state से memory corruption तक सीमित हुए सुराग

  • Holger Brunck के previous analysis के अनुसार, gdbserver हर thread के लिए kernel को SIGSTOP भेजता और response का wait करता था, लेकिन error condition में kernel सिर्फ कुछ signals पर ही respond करता था
  • lower level पर, gdbserver के साथ interaction के बाद कुछ threads गलत process state में चले गए, और उसके बाद gdbserver ने control खो दिया
  • Ariel ने PowerPC-related commit descriptions और task_struct के आसपास के changes को 3–4 दिन तक पढ़ा और check किया कि बाद के kernel versions में problem fix हुई है या नहीं, लेकिन solution नहीं मिला
  • thread_struct thread की position बदलते हुए reproduction conditions verify किए और pahole से task_struct layout देखा
  • ftrace से debug target process के threads कब schedule होते हैं, यह trace किया
    • रुके हुए threads, दूसरे threads के विपरीत, सिर्फ एक बार schedule हुए
    • इस observation से memory corruption की possibility फिर से देखी गई

Hardware breakpoint से मिला असली कारण

  • x86 के debug registers की तरह PowerPC में भी DABR register का इस्तेमाल करने वाली similar functionality है, यह confirm हुआ
  • Linux में hardware breakpoint use करने का तरीका investigate करने के बाद, Stack Overflow answer के आधार पर kernel module implement किया गया
  • इस module से task_struct.__state field पर hardware breakpoint लगाकर trace किया गया कि value कौन लिख रहा है
  • custom kernel module ने task_struct.__state पर लिखने वाली जगहों के stack traces दिखाए, और उनमें से एक अजीब path ptrace_put_fpr के buffer overflow तक जाता था
  • ptrace_put_fpr POKEUSER API में इस्तेमाल होता है, और overflow task_struct के important fields, जैसे __state, को overwrite करता है
    • __state process state store करता है
    • kernel debugger द्वारा रोके गए process को track करते समय भी इस field का उपयोग करता है

Array write जो 256 bytes तक आगे जा सकता था

  • overflow का कारण यह था कि 32-bit element array में इस्तेमाल के लिए design किए गए index को 64-bit element array पर apply किया गया
  • FPR को point करने वाला index 64 का था, और 64-bit element के हिसाब से access range 64 * 8 = 512 bytes थी
  • असली fp_state.fpr array में सिर्फ 32 entries थीं, और available memory 32 * 8 = 256 bytes थी
  • नतीजतन user, यानी gdbserver, array के end से आगे अधिकतम 256 bytes तक लिख सकता था

Upstream submission और credit conflict

  • Ariel ने माना कि process state memory को overwrite कर सकने वाली memory corruption problem का security impact हो सकता है और patch security@kernel.org को भेजा
    • यह mailing list private है, इसलिए original submitted patch link नहीं किया जा सकता था
  • PowerPC maintainer Michael Ellerman ने privately contact करके जवाब दिया कि वे issue handle करेंगे
  • Ariel ने दो fix patches भेजे
    • security mailing list को भेजा गया original patch
    • original submission पर मिले suggestions को reflect करने वाला patch का दूसरा version
  • दूसरा patch existing kernel code पर based था जो PowerPC64 पर PowerPC32 behavior emulate करता था, और वह code FPR indexing को सही तरह handle कर रहा था
  • Michael Ellerman ने दोनों patches accept नहीं किए और अपना fix implement किया
  • Ariel चाहते थे कि issue fix करने के credit और अपने पहले kernel contributor credit के लिए उनका patch accept हो, और वे feedback के आधार पर follow-up version भेजने को भी तैयार थे
  • वास्तव में मिला credit सिर्फ Reported-by tag था, और Ariel को लगा कि root cause analysis, fix, testing, verification, internal feedback incorporation, और latest kernel पर apply करने में लगाए effort की तुलना में यह unfair था
    • Linux documentation के अनुसार Reported-by bug खोजने और report करने वाले व्यक्ति को credit देने वाला tag है
    • यह issue पहले ही 6 साल पहले report हो चुका था

Updates और apology reply

  • Hacker News user ने Michael Ellerman के उस mail की ओर इशारा किया जिसमें उन्होंने लिखा था, “patch के लिए धन्यवाद, लेकिन मैं इसे अलग तरीके से fix करना चाहूंगा। क्या आप नीचे दिए गए patch को test करके confirm कर सकते हैं कि bug fix होता है?”
  • यह mail दिखाता है कि Michael Ellerman ने Ariel के patch को review करने के बजाय अपनी implementation चुनी और Ariel से उस patch को test करने के लिए कहा
  • Ariel ने security mailing list को भेजा original patch ढूंढकर linuxppc-dev पर mail thread forward किया
  • बाद के update में patch handling के तरीके पर apology reply शामिल थी
    • इसमें कहा गया था कि “आपके patch को साथ मिलकर आगे develop करने में मुझे और time देना चाहिए था”
    • इसमें यह भी कहा गया कि Reported-by tag Ariel के contribution को ठीक से reflect नहीं कर पाया

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-09-28
Hacker News की राय

  • पूरा पैच स्वीकार न भी किया जाता, तो भी Ariel Miculas को श्रेय देना ज़्यादा उचित होता
    इस security issue को शायद कोई ठीक नहीं करता अगर उन्होंने इसे ढूँढकर fix न भेजा होता
    अगर Michael ने उनका पैच पढ़कर सिर्फ कुछ style बदलाव किए और अपने नाम से submit किया, तो श्रेय न देना अनैतिक है; और code खराब भी होता, तब भी यह collaboration था, इसलिए ऐसा होने पर कोई दोबारा साथ काम नहीं करना चाहेगा

    • पहले मुझे लगता था कि किसी और का contribution लेकर अपनी branch में पूरी तरह से फिर से लिखकर merge कर देना, या GitHub PR में नए commit के रूप में rewrite कर देना ठीक है
      दूसरे मामले में फिर भी Co-Authored-By बचा रहता है, लेकिन जब किसी ने मेरे project का code commit history के बिना अपने repository में dump करके “fork” किया, तभी मुझे एहसास हुआ कि contributor के नज़रिए से यह काफी कड़वा अनुभव है
      code खराब रहा हो, फिर भी जो refactored fix merge हुआ वह उस code के बिना मौजूद नहीं होता, और “मेरा version बेहतर है” कहना काफी dismissive लग सकता है
      हालांकि maintainer के असली जवाब को link करने वाला reply देखने पर आखिरी वाक्य सही नहीं ठहरता
    • सहमत हूँ। maintainer quality की वजह से कह सकता है कि kernel में जाने वाला code वह खुद लिखेगा, और यह अपने-आप में समझ में आता है
      लेकिन इस मामले में लेखक उस patch का co-author होने के करीब है
      academic publishing से तुलना करें तो यह वैसा है जैसे आपने किसी को preprint भेजा, और उसने उसी topic पर paper निकाल दिया लेकिन आपको सिर्फ acknowledgements में रखा, co-author नहीं बनाया
      यहाँ publication नहीं बल्कि kernel development है, लेकिन author credit पेशेवर CV में अब भी महत्वपूर्ण होता है
    • अनुभवी maintainer की भूमिका मुझे facilitator जैसी लगती है, जो दूसरों के contributions को साफ-सुथरे तरीके से शामिल कराने में जितनी हो सके मदद करे
      style और structure consistency पर feedback जरूरी है, लेकिन अच्छा maintainer वह है जो credit देता है और पीछे से काम को smoothly आगे बढ़ाता है
    • जब मैंने Linux kernel में अपनी शुरुआती कुछ patches भेजीं, तब LKML के जरिए semi-automated submission भी संभव होने से पहले की बात थी, इसलिए maintainer से बातचीत करते हुए आगे बढ़ा
      उस समय Ted Tso मेरे काम की correctness से संतुष्ट हुए तो patch शामिल कर दिया, और मैंने न credit माँगा, न मिला
      मेरी दिलचस्पी सिर्फ kernel सुधारने में थी, नाम दर्ज कराने में नहीं
      कुछ साल बाद किसी और काम से contributors list में मेरा नाम आ गया, लेकिन किसी भी तरह मुझे फर्क नहीं पड़ा
    • उन्हें credit मिला था। commit में Reported-by: Ariel Miculas लिखा है, और यह सही लगता है

  • maintainer का patch बेहतर है

    1. 32-bit case में fpidx < (PT_FPSCR - PT_FPR0) check नहीं छूटता
    2. put function में fpidx range से बाहर होने पर इस्तेमाल होने वाली *data = child->thread.fp_state.fpscr; fallback assignment नहीं छूटती
    3. TS_FPRWIDTH 1 होने पर identity में बदल जाने वाले गैर-जरूरी FPRINDEX macro से बचता है
      original patch commit message में “PPC32 में TS_FPRWIDTH को 1 मान सकते हैं” कहा गया था, फिर भी FPRNUMBER, FPRHALF, FPRINDEX शामिल किए गए थे
      सिर्फ इसलिए कि किसी ने आसानी से ठीक की जा सकने वाली array mismatch ढूँढ ली, इसका मतलब यह नहीं कि buggy patch को ज्यों का त्यों accept करना चाहिए
      फिर भी maintainer को यह मानना चाहिए था कि Miculas ने सिर्फ report नहीं किया, बल्कि investigate करके root cause ढूँढा और लगभग उसी सरल fix का अपना version भी बनाया
      Reported-by यह nuance देने के लिए inaccurate है कि संबंधित व्यक्ति ने thorough investigation करके cause तक identify किया था
    • मैं मानता हूँ कि maintainer का काम बेहतर है। लेकिन वे simply patch पर code review करके update माँग सकते थे
      नए contributors के साथ projects में आम तौर पर ऐसा ही किया जाता है, और वही सही तरीका है
      यह लोगों को सिखाने और onboard करने की प्रक्रिया है; लेकिन काम को बस खुद फिर से कर देने से contribution की इच्छा कम होती है और सीखने का मौका भी खत्म हो जाता है
    • debugging कठिन है, और कभी-कभी बहुत कठिन। किसी familiar codebase में fix लिखना अपेक्षाकृत छोटा काम है, खासकर जब पिछले fix का working version guide के रूप में मौजूद हो
      दूसरा version लिखना हमेशा आसान होता है
      इसे simple fix कहना software development में bug fix करने में लगने वाले काम को न समझना है
      यहाँ Michael ने भी माना कि शुरुआत में वह reproduce नहीं कर पाए और बाद में ही confirm कर पाए
      यह OP द्वारा debugging और fix में लगाए गए काम को अच्छी तरह दिखाता है, और उस काम का credit छीनना सही नहीं है
    • “सिर्फ इसलिए कि किसी ने आसानी से ठीक की जा सकने वाली array mismatch ढूँढ ली, इसका मतलब यह नहीं कि buggy patch को ज्यों का त्यों accept करना चाहिए” कहना दूसरे की बात को जबरन तोड़-मरोड़कर पेश करना है
      मूल लेख में कहा गया था कि वह patch accept होकर credit पाना और kernel contributor बनना चाहता था, और feedback के हिसाब से follow-up version भेजने को भी तैयार था
    • कोई यह नहीं कह रहा कि original patch को ज्यों का त्यों accept करना चाहिए था
      maintainer OP का code checkout कर सकता था, अपनी मनचाही changes कर सकता था और co-author के रूप में commit करने के लिए जरूरी लगभग 2 मिनट लगा सकता था
      ऐसा करने से सबसे अच्छा fix merge होता और दूसरे व्यक्ति के काम को भी recognition मिलता
      खासकर जब OP ने साफ तौर पर कहा था कि वह credit चाहता है, इसलिए यही सबसे अच्छा होता
      हालांकि ऐसे repository maintainers अक्सर social courtesy miss कर देते हैं, इसलिए यह हैरानी की बात नहीं है
    • मैंने कई open source projects में बहुत सारे patches और PR भेजे हैं, और ज्यादातर का मकसद अपनी असुविधा दूर करना था
      PR कई वजहों से accept नहीं होते, लेकिन मुझे फर्क नहीं पड़ता
      मैं PR code को public रखने के लिए भेजता हूँ, उसे merge होने लायक “अच्छा” बनाने में समय नहीं लगाता
      जैसा है वैसा दे देता हूँ, और अगर किसी को काफी पसंद आए तो वह process संभाल ले
      कुछ वैसे ही merge हो गए, कुछ repository owner ने थोड़ा ठीक करके merge किए
      open source code मैं glory या popularity के लिए नहीं लिखता, बल्कि इसलिए क्योंकि मुझे यह पसंद है
      80s और 90s की याद आती है

  • Linux kernel कोई पुरस्कार नहीं है, और OP के प्रति सहानुभूति है, लेकिन समुदाय से आए version की बजाय maintain करने में आसान solution को prefer करना सही है
    इसलिए maintainer अपने अधिकार-क्षेत्र के भीतर था
    फिर भी fix में contribute करने वाले व्यक्ति को credit देना बहुत आसान है
    Node.js में हम release notes में credit देते हैं, और जब किसी PR के कुछ काम को लेकर उसमें बदलाव करते हैं तो Co-Authored-By: जोड़ने की कोशिश करते हैं
    लंबे समय तक maintain करते-करते credit अपने लिए कम महत्वपूर्ण लगने लगता है, इसलिए यह भूलना आसान है कि नए contributor के लिए यह बहुत महत्वपूर्ण होता है
    इस मामले में, जहाँ credit साझा करना OP के लिए महत्वपूर्ण था और उचित भी था, ज़्यादा संवेदनशील न होना OP और Linux के उस हिस्से—दोनों के लिए नुकसान है

    • अगर आपने project में काफी मेहनत लगाकर contribution को सुधारा हो और अंत में सुनने को मिले कि “मेरा version बेहतर है, अब जाओ”, तो गुस्सा आना स्वाभाविक है
      समुदाय के प्रयासों पर निर्भर project इस तरह टिकाऊ नहीं रह सकता
      Linux kernel जैसा बड़ा और सम्मानित project हो तो मुझे लगा था कि वहाँ ऐसे लोग होंगे जो project के best interest का भी ध्यान रख सकें और नए contributors का सम्मान भी कर सकें
      कोई यह नहीं कह रहा होगा कि सिर्फ नए contributor होने के कारण best न होने वाला solution स्वीकार कर लिया जाए
      सही तरीका यह है कि patch review किया जाए, बताया जाए कि क्या और क्यों समस्या है, सुझाव दिया जाए कि उसे कैसे फिर से लिखा जा सकता है, और ज़रूरत हो तो उस हिस्से को साथ में लिखकर co-author बना जाए
      तभी आगे भी रुचि रखने वाले contributors का flow बनेगा
    • “Linux kernel कोई पुरस्कार नहीं है” वाली बात इस लेख को देखकर सबसे खराब अर्थ में सही लगती है
    • लगता है उसे Reported-By tag से credit मिला था

  • kernel documentation में tag conventions में से एक के रूप में Suggested-by define किया गया है
    Suggested-by: tag यह दिखाता है कि patch idea उस व्यक्ति ने suggest किया था, और उस idea का credit सुनिश्चित करता है
    खास तौर पर कहा गया है कि अगर वह idea किसी public forum पर पोस्ट नहीं हुआ था, तो suggester की अनुमति के बिना इसे add नहीं करना चाहिए
    यह भी लिखा है कि idea बताने वाले को ईमानदारी से credit देने पर उनके भविष्य में फिर मदद करने की संभावना बढ़ती है
    इस स्थिति में Suggested-by शायद ज़्यादा उपयुक्त हो सकता था
    यह बात बेहतर तरीके से बताता कि समस्या का solution उसने खोजा था, लेकिन project से परिचित न होने के कारण patch की सटीक syntax maintain नहीं रह पाई
    संदर्भ: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

    • मैंने patches की तुलना नहीं की है, लेकिन नीचे comment [1] के अनुसार accepted patch और proposed patch के बीच एकमात्र फर्क fix की जगह का था
      एक if के बाहर वाले ifdef में है, और दूसरा अंदर के if statement में—यानी यह technical difference नहीं बल्कि style difference है
      अगर ऐसा है, तो author ने सिर्फ patch idea “suggest” करने से कहीं ज़्यादा किया
      उसने issue debug किया और पूरा patch लिखा, और बस एक छोटे-से change के साथ वह स्वीकार हो गया
      1: https://news.ycombinator.com/item?id=37672558
    • वह तरीका भी संभव है, लेकिन non-security issue के मामले में ज़्यादा fit लगता है
      security issue में format से ज़्यादा speed और accuracy महत्वपूर्ण होते हैं, और kernel maintainers ने Reported-by से credit देकर सही तरीके से handle किया
      Suggested-by थोड़ा बेहतर होता, लेकिन OP जो चाहता है वह यह नहीं है; OP बहुत छोटे patch के आधार पर “kernel contributor” का label चाहता था, ऐसा लगता है

  • इस thread में कुछ प्रतिक्रियाएँ देखकर लगता है कि कुछ लोगों को खासकर junior या mid-level developers को manage नहीं करना चाहिए
    अगर आपकी team में कोई उत्साही junior है और उसने किसी issue में मदद करने वाला, लेकिन quality में कमजोर PR भेजा है, तो उसे “काफी अच्छा नहीं है” कहकर डाँटना, code फेंक देना और फिर खुद से दोबारा लिखना सबसे खराब प्रतिक्रिया है
    इससे उसका morale टूटता है, उसका और आपका समय बर्बाद होता है, वह कुछ सीख नहीं पाता, अगली बार बेहतर करने या meaningful योगदान देने से रुकता है, और मदद माँगने या खुद से योगदान देने में भी हिचकने लगता है
    अगर वह किसी complex code area में कूद पड़ा हो, तब भी interaction के बेहतर तरीके होते हैं

    • किसी company या team में junior को manage और coach करना, और internet पर किसी random व्यक्ति का छोटा patch भेजना, अलग बातें हैं
      team का junior कुछ समय तक रहेगा, यह उम्मीद होती है, और interview के जरिए उसकी basic क्षमता भी कुछ हद तक verify की गई होती है, इसलिए उसकी growth potential पर भरोसा किया जा सकता है
      internet पर random व्यक्ति के बने रहने की कोई obligation नहीं होती, और ऐसे “drive-by” fixes में अधिकतर लोग टिकते नहीं हैं
      यह भी नहीं पता होता कि उस व्यक्ति की असल capability क्या है, या वह change requests पर कैसे react करेगा
      management perspective से सबसे frustrate करने वाली चीजों में से एक है कि कोई किसी random व्यक्ति को मेरी reporting line में डाल दे और मुझे उसके performance के लिए जिम्मेदार बना दे
      अब कल्पना कीजिए कि internet पर entitlement से भरा कोई व्यक्ति कुछ दिन लगाकर low-quality fix बनाता है, और मुझसे उम्मीद की जाती है कि मैं उसके manager की तरह उसे coach करूँ—यह analogy समझ में नहीं आती
      पहले मुझे हैरानी होती थी कि GitHub पर project host करने पर unwanted PRs को लेकर इतना हंगामा क्यों होता है, लेकिन अब समझ आता है
      अगर random PRs से deal नहीं करना चाहते तो आपको “morale तोड़ने और समय बर्बाद कराने वाला खराब manager” कहा जाए—यह excessive entitlement है
      उदाहरण: https://news.ycombinator.com/item?id=25940799
    • अगर कोई जरूरत से ज्यादा उत्साही junior एक हफ्ते तक ऐसी चीज हल करता रहा जो priority भी नहीं थी और उसका assigned काम भी नहीं था, तो आप उसे अलग बुलाकर कह सकते हैं, “इसे अभी hold पर रखते हैं और बाद में फिर देखेंगे। अभी X priority है, इसलिए हम इस पर समय नहीं दे सकते”
      professional बनना अपने आप को अपने काम से अलग करना सीखना भी है, और यह समझना भी कि आपका colleague किसी malicious plan के तहत आपको रोकने की कोशिश नहीं कर रहा
      हर किसी का कई महीनों का project कभी न कभी cancel हुआ है, और code review में कठोर comments मिले हैं
      ऐसी चीजों को स्वीकार करना और उनसे सीखना professional होने का हिस्सा है
      बेशक, blunt और rude लोगों को भी यह सीखना चाहिए कि ऐसा attitude कई रिश्ते खराब कर देता है
      हम कलाकार नहीं, professionals हैं
      अगर किसी junior civil engineer ने structural flaws वाला bridge design किया और senior ने कहा, “माफ़ करना, लेकिन इसे अब बचाना मुश्किल है, इसलिए सब कुछ फिर से करना पड़ेगा,” तो senior गलत नहीं है
      junior के आत्मसम्मान को बचाने के लिए मैं कमजोर bridge पर drive नहीं करना चाहूँगा
      ऐसा लगता है कि बड़े open source projects maintain करने का ज्यादा अनुभव न रखने वाले comments maintainers को असामान्य रूप से कठोर मान रहे हैं
      छोटा open source project maintain करके देखें, random व्यक्ति का PR लेना काफी काम होता है, और अक्सर खुद करने से ज्यादा समय लेता है
      code को ध्यान से review करने, contributor से बात करके issues fix कराने, और expected quality व conventions से match कराने में बहुत समय लगता है
      workplace junior interview से होकर आया होता है, लेकिन यहाँ कोई random stranger change request कर रहा है
      PR reject होने पर बुरा लगता है, लेकिन मैं दोनों पक्षों को समझता हूँ
      maintainer की बातचीत देखकर वह खास तौर पर mean या rude नहीं लगता
    • इसे फिर से पढ़ना बेहतर होगा। असल में ऐसा हुआ हो, ऐसा नहीं दिखता; कम से कम यह एक पक्ष की भावनात्मक reconstruction हो सकती है
    • सच में निराशाजनक है कि इस thread में इतने harsh comments हैं
      यह लगभग LKML के किसी खराब thread जैसा लग रहा है
      उस व्यक्ति ने सचमुच 95% काम किया, फिर भी credit चाहने पर उसकी आलोचना हो रही है
      आखिर ऐसा क्यों है, समझ नहीं आता
    • यह thread खराब interpersonal relationships को सामने लाने वाली lightning rod जैसा है, और HN readers की age range देखते हुए काफी शर्मनाक है

  • दोनों patches की तुलना करें तो साफ अंतर दिखता है
    linked post वाला contribution if...else की दोनों branches का behavior बदलता है, जबकि final contribution केवल if branch के अंदर का path बदलता है
    maintainer ने code बदलने के पीछे कोई कारण रखा होगा
    फिर भी असली fix लगभग 100% copy किया गया था, इसलिए original patch author को credit देना उचित होता

    • ऊपर की mail conversation में original patch भी ऐसा ही था
      original result में PPC32 architecture पर न flush_fp_to_thread था और न else condition
      final patch flush_fp_to_thread(child); call करता है, fpidx range check के अंदर CONFIG_PPC32 है या नहीं उसके आधार पर handle करता है, और range के बाहर होने पर fpscr assign करता है
      इसलिए दोनों solutions के बीच वास्तविक अंतर है
      कौन सा सही या बेहतर है, यह नहीं कह सकता, लेकिन result अलग है, यह साफ है
    • लंबे समय से C इस्तेमाल करने वाले के रूप में, custom macros से भरा code आए तो मैं सतर्क हो जाऊँगा
      यह C की अपरिपक्व समझ का संकेत भी हो सकता है
      बड़े codebase का maintenance आधा firefighting है और आधा name collision avoidance
    • मैं post author हूँ। दुर्भाग्य से मैंने जो original patch भेजा था वह केवल Linux kernel security mailing list को भेजा था, इसलिए उसे link नहीं कर सकता
      वह patch काफी अलग था, काश मैंने उसे दिखाने के लिए कहीं save कर लिया होता

  • यह kernel contribution का सामान्य हिस्सा है
    अक्सर समस्या को सबसे संक्षिप्त तरीके से बताने का तरीका patch ही होता है, इसलिए patch भेजा जाता है, और expectation यह होनी चाहिए कि वे उस patch को इस्तेमाल नहीं करेंगे
    याद आते ही मेरे साथ ऐसा कम-से-कम तीन बार [1][2][3] हुआ है
    सच कहूं तो मैंने कभी गुस्सा होने के बारे में सोचा भी नहीं, क्योंकि मेरा मुख्य लक्ष्य bug ठीक करना था और वह हो गया, इससे मैं खुश था
    OP को मेरी सच्ची सलाह है कि यह blog post हटा देना बेहतर होगा। बाद में पछतावा होगा
    [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...

    • दूसरे व्यक्ति का नाम सार्वजनिक कर उसे बस के नीचे धकेलना सच में बहुत खराब लगता है
      दूसरे व्यक्ति का नाम देखकर मुझे काफी हैरानी हुई

  • open source projects में ऐसा हमेशा होता रहता है, और आखिर में इससे आगे contribute करने का उत्साह ही टूटता है
    पिछले साल मैंने कई साल से खुले पड़े एक issue को लिया, PR बनाया, test code भी ठीक किया, और build problem ठीक करने के लिए अलग काम भी किया
    maintainer ने सिर्फ build problem ठीक करने वाला PR लिया और असली issue को बस ignore कर दिया
    उस project में फिर से समय लगाकर contribute करने की कोई संभावना नहीं है

    • कुछ लोगों का पूरा GitHub resume copy-paste किए गए contributions से बना होता है
      आप PR खोलते हैं, change request comments मिलते हैं
      कुछ दिन बाद समय मिलने पर जब आप उसे ठीक करने जाते हैं, तो वह पहले ही किसी frequent contributor के दूसरे PR से बंद हो चुका होता है
      उस PR को देखें तो वह मेरे code जैसा ही होता है, बस एक variable name बदला होता है, और “friend” review standard से तुरंत approve हो जाता है
      उस व्यक्ति की profile देखें तो लगभग सभी contributions दूसरों का code copy किए हुए होते हैं
    • एक छोटे project maintainer के तौर पर, मुझे अच्छा लगता है जब लोग code या tests contribute करते हैं
      मैं उन्हें codebase के बाकी हिस्से के मुताबिक साफ-सुथरा करने में मदद करने की कोशिश करता हूं, लेकिन यही सबसे मुश्किल होता है
      क्योंकि ज्यादातर developers project conventions पहले सीखने के बजाय बस अपना fix धकेल देना चाहते हैं
      फिर भी अगर code मोटे तौर पर सही है और merge के बाद मुझे करीब 15 मिनट polish करके थोड़े और tests जोड़ने भर की जरूरत है, तो मैं उसे accept कर लेता हूं
      यह मामला भी वैसा ही लगता है, और maintainer को ऐसा ही करना चाहिए था
      contributor को credit मिलता, maintainer को upstream में accept होने लायक जरूरी cleanup में बस कुछ मिनट लगाने पड़ते, और सब खुश होते
      “मेरी version बेहतर है” कहना, चाहे सच में बेहतर हो या नहीं, बहुत घमंडी और unprofessional है
      अगर issue पहली बार report होने के बाद 6 साल तक ठीक नहीं कर पाए, तो यह मानना चाहिए कि उस व्यक्ति के contribution के बिना आपका fix भी नहीं होता
      “solution” देखने के बाद उस fix को ले लेना असल में चोरी के काफी करीब है
    • मेरे अनुभव में code projects को जो contribution चाहिए होता है वह bug reports और improvement ideas होते हैं, जरूरी नहीं कि आपका code हो
      लोग अपना code accept न होने या rewrite होने पर इसे personal ले लेते हैं, लेकिन project चलाने में code लिखना बस एक छोटा हिस्सा है, यह बात वे चूक जाते हैं
    • यह आम समस्या है
      मैं आम तौर पर bug reports और merge requests देखकर अंदाजा लगाता हूं कि patch के साथ कैसा व्यवहार होगा
      जिन projects में contribute करना अच्छा नहीं लगता, उनमें मैंने कई bug fixes यूं ही छोड़ दिए, और 2003 का Linux kernel भी ऐसा ही उदाहरण था
      कुछ projects बस ऐसे ही होते हैं, उनसे न जुड़ना बेहतर है, और अक्सर यह समय की बर्बादी बनता है
      अब AI revolution के बाद open source licenses का व्यापक उल्लंघन हो रहा है, इसलिए उसके बाद से मैंने open source code submit नहीं किया और आगे भी नहीं करूंगा

  • यहां की toxicity को समझना सच में मुश्किल है
    “recognition, stars, rewards, resume जैसी चीजों के लिए नहीं करना चाहिए” जैसी बातें पागलपन लगती हैं
    ऐसी बातें कहने वाले लोगों के पास नौकरी है? अगर है, तो consistency के लिए उन्हें पूरी तरह मुफ्त में काम करना चाहिए
    salary भी contribution के लिए recognition का एक रूप है
    व्यक्तिगत रूप से, final solution प्रस्तावित solution से अलग हो गया हो तब भी, अगर वह original solution की खोज पर आधारित था, तो co-author जोड़ना बहुत छोटी बात है
    author के पास इस बारे में शिकायत करने की वैध वजह है, और यह पहली या आखिरी बार नहीं होगा जब किसी को लगे कि उसके contribution को recognition नहीं मिला

    • लोग ऐसे बर्ताव कर रहे हैं जैसे हम code robots हों जिन्हें अपने अच्छे काम के लिए कोई recognition बिल्कुल नहीं चाहिए
      patch खुद घटिया रहा हो, तब भी debugging effort कभी घटिया नहीं था
    • employment relationship से यह अलग स्थिति है
      employment में employer और employee compensation के बदले काम करने का agreement करते हैं
      अगर आप बिना बताए किसी company में घुसकर ऐसा काम शुरू कर दें जिसे किसी ने मांगा ही नहीं, तो बहुत कम लोग कहेंगे कि आपको compensation पाने का अधिकार है
      OP के साथ जो हुआ उसका ज्यादा सटीक analogy यही है
    • original author को credit देना और खुद को editor के रूप में पेश करना ज्यादा fair होता

  • “माफ़ कीजिए, लेकिन मेरा version बेहतर है। अगर आप Linux kernel contributor बनना चाहते हैं, तो यहाँ एक issue है जिसे आप ठीक कर सकते हैं” जैसे response देना, यह सुनिश्चित करने का शानदार तरीका है कि कोई व्यक्ति फिर कभी मदद न करे और दूसरों का उत्साह भी टूट जाए

    • वास्तविक wording अलग थी
      maintainer ने कहा कि वे gdbserver से crash reproduce नहीं कर पाए, लेकिन उनके पास bug दिखाने वाला test case था, इसलिए उन्होंने verify किया और fix test किया; और लिखा, “patch के लिए धन्यवाद, लेकिन मैं इसे अलग तरह से ठीक करना चाहता था। क्या आप नीचे वाला patch try करके देख सकते हैं कि bug ठीक होता है या नहीं?”
      https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...
      इसके अलावा कुछ और review comments भी थे जिनका ज़िक्र नहीं किया गया
      उनका कहना था कि समझ नहीं आता कि सिर्फ PPC32 के लिए macro का क्या फायदा है, #ifdef से जहाँ तक हो सके बचना चाहिए, और Michael का patch समझने में आसान है
      https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...
    • maintainer ने असल में ऐसा नहीं कहा था
      OP दूसरे व्यक्ति के मुँह में अपनी बात डालकर उसी पर नाराज़ हो रहा है, और खासकर text communication में यह अच्छी strategy नहीं है
    • खासकर जब OP ने लिखा था कि यह issue 6 साल पहले report होने के बाद ignore कर दिया गया था, तब maintainer का व्यवहार काफ़ी खराब लगता है
    • असल में ऐसा हुआ ही नहीं था
      OP बातचीत को rude दिखाने की कोशिश करता है, लेकिन वास्तव में वह ऐसी नहीं थी
    • फिर भी, इसकी क्या guarantee है कि maintainer अगली बार भी “मेरा version बेहतर है” कहते हुए किसी दूसरे bug की तरफ़ इशारा नहीं करेगा?