2 điểm bởi GN⁺ 2023-09-28 | 1 bình luận | Chia sẻ qua WhatsApp
  • Tác giả đang xử lý một vấn đề gỡ lỗi trong một dự án bao gồm gdbserver và ứng dụng đa luồng chạy trên kiến trúc PowerPC32.
  • Vấn đề là kết nối tới gdbserver bị ngắt, khiến họ không còn có thể điều khiển phiên debug nữa.
  • Sau khi nghiên cứu và điều tra, tác giả tìm thấy một chuỗi email chỉ ra chính xác commit đã gây ra vấn đề này.
  • Tác giả đã dành 3-4 ngày để đọc mô tả commit liên quan đến kiến trúc PowerPC và những thay đổi xung quanh task_struct, đồng thời cố gắng xác định liệu vấn đề này đã được khắc phục ở các phiên bản kernel sau đó hay chưa.
  • Tác giả đã sử dụng nhiều công cụ và kỹ thuật khác nhau, như di chuyển luồng thread_struct, kiểm tra layout của task_struct bằng pahole, và dùng ftrace để xác định khi nào các luồng của tiến trình đang được debug được lên lịch chạy.
  • Tác giả phát hiện đây có thể là một vấn đề hỏng bộ nhớ, vì luồng bị kẹt chỉ được lên lịch một lần, khác với các luồng khác.
  • Tác giả đã triển khai một module Linux kernel để sử dụng hardware breakpoint trên Linux, và đặt hardware breakpoint vào trường __state để xác định ai đã ghi vào đó.
  • Tác giả phát hiện vấn đề là do tràn bộ đệm trong ptrace_put_fpr (được API POKEUSER sử dụng), khiến các trường quan trọng của task_struct, chẳng hạn như __state, bị ghi đè.
  • Vì vấn đề này có thể dẫn đến rủi ro bảo mật, tác giả đã gửi một bản vá tới nhóm bảo mật Linux kernel (security@kernel.org) để khắc phục nó.
  • Thay vì chấp nhận bản vá của tác giả, maintainer PowerPC là Michael Ellerman đã tự triển khai phiên bản sửa lỗi của riêng mình.
  • Tác giả cảm thấy công việc của mình không được ghi nhận đúng mức, bị xem nhẹ và rất tức giận. Họ chỉ nhận được thẻ "Reported-by".
  • Đóng góp kernel đầu tiên của tác giả là một trải nghiệm đầy thất vọng và nản lòng, với những cuộc trao đổi cùng những người dường như không coi trọng việc ghi nhận xứng đáng cho công sức của người khác.

1 bình luận

 
GN⁺ 2023-09-28
Ý kiến trên Hacker News
  • Bài viết về tình huống bản vá của người đóng góp không được chấp nhận nguyên vẹn, nhưng người bảo trì đã dùng ý tưởng đó để khắc phục một vấn đề bảo mật
  • Một số bình luận cho rằng dù bản vá hoàn chỉnh không được nhận, người bảo trì vẫn nên ghi công cho người đóng góp
  • Một số ý kiến khác cho rằng bản vá của người bảo trì tốt hơn và hiệu quả hơn, nhưng vẫn cần ghi nhận việc người đóng góp đã xác định vấn đề và đề xuất giải pháp
  • Một số bình luận nhấn mạnh rằng Linux kernel không phải là phần thưởng và người bảo trì có quyền chọn giải pháp tốt nhất, đồng thời cũng nhấn mạnh tầm quan trọng của việc ghi công cho người đóng góp
  • Nhắc đến thẻ "Suggested-by" trong tài liệu kernel như một cách để ghi công cho người đã đề xuất ý tưởng bản vá
  • Một số bình luận nói rằng đây là phần bình thường của việc đóng góp cho kernel, và mục tiêu chính là sửa lỗi chứ không phải nhận công lao
  • Các bình luận chia sẻ trải nghiệm bị phớt lờ hoặc không được chấp nhận hoàn toàn trong các dự án mã nguồn mở, điều này có thể cản trở những đóng góp tiếp theo
  • Các bình luận so sánh bản vá của người đóng góp với bản vá của người bảo trì, chỉ ra khác biệt và cho rằng nên ghi công cho tác giả ban đầu
  • Cuộc thảo luận cũng đề cập đến tầm quan trọng của việc xử lý đóng góp của các thành viên cấp dưới theo cách khuyến khích học hỏi và cải thiện
  • Một bình luận bày tỏ sự khó hiểu trước phản ứng tiêu cực, cho rằng sự ghi nhận là quan trọng và việc thêm đồng tác giả là một cử chỉ nhỏ nhưng có ý nghĩa
  • Cuộc thảo luận kết lại bằng các bình luận về tầm quan trọng của sự khéo léo trong ứng xử và việc duy trì quan hệ lâu dài trong các dự án mã nguồn mở