pwritev2 RWF_APPEND can overwrite a concurrent append
Maintainer thường phản hồi trong vòng 2 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 30/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- c, macos
- Lĩnh vực
- operating-systems
Hướng nghiên cứu
Start in src/syscall/io.c at sys_pwritev_append, then compare the O_APPEND paths in sys_pwrite64 and sys_pwritev. The issue describes a race but no safe approach for descriptors without O_APPEND; investigate available host mechanisms while accounting for shared file-description flags. Done means concurrent RWF_APPEND writes do not overwrite one another, including on descriptors opened without O_APPEND.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
pwritev2 with RWF_APPEND (sys_pwritev_append in src/syscall/io.c) reads the end of file with fstat and then writes there with pwritev, in two host calls. Linux finds the end of file and writes under the inode lock, so two processes appending to one file with RWF_APPEND never overwrite each other. Under elfuse both can read the same st_size, and the second write lands on the first one's bytes while each call returns success.
For a descriptor that is already O_APPEND, sys_pwrite64 and sys_pwritev now route the write through the host's own append (#463), and RWF_APPEND on such a descriptor could share that path. For a descriptor opened without O_APPEND, macOS has no call that appends atomically without changing the open file description's flags. Setting O_APPEND with F_SETFL around the write would change the flags that a forked child and sibling threads share.
Found in review on #463. It is not changed there because the same fstat then pwritev shape exists on main.
- Ngôn ngữ chính
- C
- Star
- 278
- Fork
- 31
- Merge trung bình
- 2 ngày 18 giờ
- Pull request đã merge (30 ngày)
- 16
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của sysprog21/elfuse
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
Maintainer thường phản hồi trong vòng 2 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 2 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 55/100
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 52/100
Maintainer thường phản hồi trong vòng 2 ngày
Tất cả issue của sysprog21/elfuse
Issue tương tự
-
documentation
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 72/100
-
BUG: `tandg` and `cotdg` lose precision near their poles, `fresnel` is NaN for `|x| >= 2^512`Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
Maintainer thường phản hồi trong vòng 1 ngày
-
0.kind: build failure
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 79/100
Maintainer thường phản hồi trong vòng 2 ngày