ผลงานการมีส่วนร่วมกับเคอร์เนลครั้งแรกของฉันถูกขโมยไป

• ผู้เขียนกำลังจัดการปัญหาการดีบักในโปรเจ็กต์ที่มี gdbserver ทำงานอยู่บนสถาปัตยกรรม PowerPC32 และมีแอปพลิเคชันแบบหลายเธรด
• ปัญหาคือการเชื่อมต่อกับ gdbserver หลุด ทำให้ไม่สามารถควบคุมเซสชันดีบักได้อีกต่อไป
• หลังจากการค้นคว้าและตรวจสอบ ผู้เขียนพบเธรดอีเมลที่ชี้ไปยังคอมมิตที่แน่ชัดซึ่งเป็นสาเหตุของปัญหานี้
• ผู้เขียนใช้เวลา 3-4 วันอ่านคำอธิบายคอมมิตที่เกี่ยวข้องกับสถาปัตยกรรม PowerPC และการเปลี่ยนแปลงรอบ ๆ task_struct พร้อมพยายามหาว่าปัญหานี้ถูกแก้ในเคอร์เนลเวอร์ชันถัดไปแล้วหรือไม่
• ผู้เขียนใช้เครื่องมือและเทคนิคหลากหลาย เช่น การย้ายเธรด thread_struct, การตรวจสอบเลย์เอาต์ของ task_struct ด้วย pahole และการใช้ ftrace เพื่อดูว่าเธรดของโปรเซสที่กำลังดีบักถูกจัดตารางเวลาเมื่อใด
• ผู้เขียนพบว่าปัญหาอาจเป็นเรื่องหน่วยความจำเสียหาย โดยเธรดที่ค้างถูกจัดตารางเวลาเพียงครั้งเดียว ต่างจากเธรดอื่น
• ผู้เขียนใช้ฮาร์ดแวร์เบรกพอยต์บน Linux และเขียนโมดูลเคอร์เนล Linux เพื่อวางฮาร์ดแวร์เบรกพอยต์บนฟิลด์ __state เพื่อดูว่าใครเป็นคนเขียนค่าลงไป
• ผู้เขียนพบว่าปัญหาเกิดจากบัฟเฟอร์โอเวอร์โฟลว์ใน ptrace_put_fpr (ซึ่ง API POKEUSER ใช้งาน) ทำให้ฟิลด์สำคัญใน task_struct เช่น __state ถูกเขียนทับ
• ผู้เขียนมองว่าปัญหานี้อาจนำไปสู่ประเด็นด้านความปลอดภัย จึงส่งแพตช์ไปยังทีมความปลอดภัยของลินุกซ์เคอร์เนล ([e-mail]) เพื่อแก้ไขปัญหานี้
• แทนที่จะรับแพตช์ของผู้เขียน Michael Ellerman ผู้ดูแล PowerPC กลับเขียนวิธีแก้เวอร์ชันของตนเองขึ้นมา
• ผู้เขียนรู้สึกว่าผลงานของตนไม่ได้รับการยอมรับอย่างเหมาะสม ถูกมองข้าม และรู้สึกโกรธ เพราะได้รับเพียงแท็ก Reported-by เท่านั้น
• การมีส่วนร่วมกับเคอร์เนลครั้งแรกของผู้เขียนจึงเป็นประสบการณ์ที่เต็มไปด้วยความหงุดหงิดและความท้อแท้ จากการพูดคุยกับผู้คนที่ดูเหมือนไม่เห็นความสำคัญของการให้เครดิตอย่างเหมาะสมกับงานของผู้อื่น

[GN⁺]

ความคิดเห็นบน Hacker News

• บทความเกี่ยวกับกรณีที่แพตช์ของผู้มีส่วนร่วมไม่ได้ถูกรับเข้าไปทั้งหมด แต่ผู้ดูแลได้นำแนวคิดนั้นไปใช้เพื่อแก้ปัญหาด้านความปลอดภัย
• ความคิดเห็นบางส่วนมองว่า แม้แพตช์ฉบับเต็มจะไม่ได้ถูกรับเข้าไป ผู้ดูแลก็ควรให้เครดิตแก่ผู้มีส่วนร่วม
• อีกฝ่ายแย้งว่าแพตช์ของผู้ดูแลดีกว่าและมีประสิทธิภาพกว่า แต่ก็ยังควรยอมรับว่าผู้มีส่วนร่วมเป็นผู้ระบุปัญหาและเสนอแนวทางแก้
• บางความคิดเห็นเน้นว่า Linux kernel ไม่ใช่เรื่องของรางวัล และผู้ดูแลมีสิทธิ์เลือกวิธีแก้ที่ดีที่สุด พร้อมทั้งย้ำความสำคัญของการให้เครดิตแก่ผู้มีส่วนร่วม
• มีการกล่าวถึงแท็ก Suggested-by ในเอกสารของเคอร์เนลว่าเป็นวิธีให้เครดิตแก่ผู้ที่เสนอแนวคิดของแพตช์
• บางความคิดเห็นบอกว่านี่เป็นเรื่องปกติของการมีส่วนร่วมกับเคอร์เนล และเป้าหมายหลักคือการแก้บั๊ก ไม่ใช่การได้รับเครดิต
• มีความคิดเห็นที่แชร์ประสบการณ์ว่าผลงานของตนในโครงการโอเพนซอร์สถูกมองข้ามหรือไม่ได้รับการยอมรับทั้งหมด ซึ่งอาจทำให้ไม่อยากมีส่วนร่วมเพิ่มเติม
• มีความคิดเห็นเปรียบเทียบแพตช์ของผู้มีส่วนร่วมกับแพตช์ของผู้ดูแล ชี้ให้เห็นความแตกต่าง และเสนอว่าควรให้เครดิตแก่ผู้เขียนต้นฉบับ
• ยังแตะประเด็นการดูแลผลงานของสมาชิกทีมรุ่นน้องในแบบที่ส่งเสริมการเรียนรู้และการพัฒนา
• มีความคิดเห็นที่แสดงความสับสนต่อกระแสตอบรับเชิงลบ โดยยืนยันว่าการยอมรับมีความสำคัญ และการเพิ่มชื่อเป็นผู้ร่วมเขียนก็เป็นท่าทีเล็ก ๆ แต่มีความหมาย
• การสนทนาปิดท้ายด้วยความคิดเห็นเกี่ยวกับความสำคัญของการมีชั้นเชิงและการรักษาความสัมพันธ์ระยะยาวในโครงการโอเพนซอร์ส