Ma première contribution au noyau a été volée

• L’auteur travaillait sur un problème de débogage dans un projet incluant gdbserver et une application multithread s’exécutant sur l’architecture PowerPC32.
• Le problème était que la connexion à gdbserver se coupait, rendant impossible tout contrôle ultérieur de la session de débogage.
• Après des recherches et une enquête, l’auteur a trouvé un fil d’e-mails pointant vers le commit exact à l’origine du problème.
• L’auteur a passé 3 à 4 jours à lire les descriptions de commits liées à l’architecture PowerPC et aux changements autour de task_struct, en essayant de déterminer si le problème avait été corrigé dans des versions ultérieures du noyau.
• L’auteur a utilisé divers outils et techniques, notamment le déplacement de thread_struct, l’inspection de la disposition de task_struct avec pahole, et l’utilisation de ftrace pour déterminer quand les threads du processus débogué étaient planifiés.
• L’auteur a découvert que le problème pouvait être une corruption mémoire, car le thread bloqué n’était planifié qu’une seule fois, contrairement aux autres threads.
• L’auteur a utilisé des points d’arrêt matériels sous Linux et a implémenté un module du noyau Linux afin de placer un point d’arrêt matériel sur le champ __state pour identifier qui y écrivait.
• L’auteur a découvert que le problème venait d’un débordement de tampon dans ptrace_put_fpr (utilisé par l’API POKEUSER), qui écrasait des champs critiques de task_struct, comme __state.
• Comme ce problème pouvait entraîner un risque de sécurité, l’auteur a envoyé un correctif à l’équipe de sécurité du noyau Linux ([e-mail]) pour le résoudre.
• Au lieu d’accepter le correctif de l’auteur, le mainteneur PowerPC Michael Ellerman a implémenté sa propre version de la correction.
• L’auteur s’est senti sous-estimé et en colère, estimant que son travail n’avait pas été correctement reconnu. Il n’a reçu qu’un tag Reported-by.
• La première contribution de l’auteur au noyau a été une expérience remplie de frustration et de découragement, marquée par des échanges avec des personnes qui ne semblaient pas considérer comme important d’accorder une reconnaissance appropriée au travail des autres.

[GN⁺]

Avis Hacker News

• Article sur une situation où le correctif du contributeur n’a pas été entièrement accepté, mais où le mainteneur a utilisé l’idée pour résoudre un problème de sécurité
• Certains commentaires estiment que même si le correctif complet n’a pas été accepté, le mainteneur aurait dû créditer le contributeur
• D’autres avancent que le correctif du mainteneur est meilleur et plus efficace, tout en reconnaissant qu’il faut saluer le fait que le contributeur ait identifié le problème et proposé une solution
• Certains commentaires soulignent que le noyau Linux n’est pas une récompense et que le mainteneur a le droit de choisir la meilleure solution, tout en insistant sur l’importance d’accorder du crédit au contributeur
• Mention du tag Suggested-by dans la documentation du noyau comme moyen de créditer la personne ayant proposé l’idée du correctif
• Certains commentaires indiquent que cela fait partie du fonctionnement habituel des contributions au noyau et que l’objectif principal est de corriger les bugs, pas d’obtenir du crédit
• Des commentaires partagent des expériences où leurs contributions ont été ignorées ou pas entièrement acceptées dans des projets open source, ce qui peut décourager de contribuer davantage
• Des commentaires comparent le correctif du contributeur et celui du mainteneur, en pointant leurs différences et en suggérant que l’auteur original aurait dû être crédité
• La discussion aborde aussi l’importance de traiter les contributions des membres juniors de l’équipe d’une manière qui encourage l’apprentissage et l’amélioration
• Un commentaire exprime sa confusion face aux réactions négatives, affirmant que la reconnaissance est importante et qu’ajouter un co-auteur est un petit geste, mais significatif
• La discussion se conclut par des commentaires sur l’importance de la diplomatie et du maintien de relations de long terme dans les projets open source