kernel_copy: avoid panic on unexpected OS error #91153
Conversation
|
r? @yaahc (rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
I think this might be an upstream bug or if FUSE is involved then a bug in that code and should be reported in the appropriate place instead of being papered over, no? The assert simply surfaces something breaking the documented syscall API, so the bug lies there. Edit: Nevermind, if we still bubble up the error we're not exactly papering over it. That may be good enough, even though not as loud as I'd like. |
|
The question is how well-defined the syscall API really is. At least the manpage doesn't include wording like "if errno is X, Y or Z, no bytes can have been written", but only says "On error, copy_file_range() returns -1 and errno is set to indicate the error." 🤷♂️ |
According to documentation, the listed errnos should only occur if the `copy_file_range` call cannot be made at all, so the assert be correct. However, since in practice file system drivers (incl. FUSE etc.) can return any errno they want, we should not panic here. Fixes rust-lang#91152
birkenfeld
force-pushed
the
kernel_copy_fallback
branch
from
7655d35
to
b490ccc
Compare
|
@bors r+ |
|
📌 Commit b490ccc has been approved by |
bors
added
S-waiting-on-bors
the8472
added
the
T-libs
…askrgr Rollup of 6 pull requests Successful merges: - rust-lang#90856 (Suggestion to wrap inner types using 'allocator_api' in tuple) - rust-lang#91103 (Inhibit clicks on summary's children) - rust-lang#91137 (Give people a single link they can click in the contributing guide) - rust-lang#91140 (Split inline const to two feature gates and mark expression position inline const complete) - rust-lang#91148 (Use `derive_default_enum` in the compiler) - rust-lang#91153 (kernel_copy: avoid panic on unexpected OS error) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
According to documentation, the listed errnos should only occur
if the
copy_file_rangecall cannot be made at all, so theassert be correct. However, since in practice file system
drivers (incl. FUSE etc.) can return any errno they want, we
should not panic here.
Fixes #91152