fcntl_setpipe_size should handle error cases (EBUSY, EPERM)

[xtqqczze]

fcntl_setpipe_size currently ignores error cases when setting pipe size:

let _ = fcntl_setpipe_size(&mut *dest, MAX_ROOTLESS_PIPE_SIZE);

This can silently drop failures from F_SETPIPE_SZ, which may occur in at least the following cases:

• EBUSY
• EPERM

[gabrielhnf]

I thought setting the pipe size was purely an optimization, is there a specific case where silently ignoring these errors causes incorrect behavior?

[oech3]

We should not raise error what GNU does not raise.
You should not open an issue if you cannot test GNU coreutils by strace on Linux.

[oech3]

I thought setting the pipe size was purely an optimization, is there a specific case where silently ignoring these errors causes incorrect behavior?

If we absolutely need the specified size by some reason (e.g. writing the size should not hang), we need to catch them.

[xtqqczze]

We should not raise error what GNU does not raise.

I’m not suggesting propagating an error. But we should handle the failure case gracefully, matching GNU behavior by falling back to a smaller pipe size.

[oech3]

I really really did not want to say that, but I think @xtqqczze is just taking it out on people on Linux since you cannot use them on your macOS. This issue is invalid and should be opened with specific example with strace.

[oech3]

But we should handle the failure case gracefully, matching GNU behavior by falling back to a smaller pipe size.

No need. splice(2) truncates length. Rust std specifies ~2GiB splice.

[xtqqczze]

@oech3 I’d like to keep the discussion focused on the technical issue rather than personal assumptions. The tone of the comment is not constructive and makes collaboration harder.

[oech3]

@xtqqczze I really really did not want to say that, but you started destructive way 1st.

[oech3]

(I'm open to talk about fixing actuall examples for bugs)

[xtqqczze]

@oech3 I’m not interested in arguing about who started what. I would appreciate avoiding personal characterizations going forward, and I think withdrawing the earlier remarks would help keep the discussion constructive.

[oech3]

You deliberately opened coflicts with many my PRs after you saw my PRs. This is a fact.
Ofcause pure-technical discussion only is ideal, but there are people on here, not bots.
This thread shuld be locked and converted to discussion.

[xtqqczze]

@oech3 I’ve closed any conflicting PRs to help keep things focused on the technical issue. I’m also happy to remove comments on my side if that helps de-escalate, and I’d appreciate if the same could be done for the personal remarks as well. If we can agree to avoid personal characterizations going forward, we can continue this as a technical discussion without further escalation.

[oech3]

Let hide as off-topic instead of removing. So people can audit them if needed.

[oech3]

One of a possible error is buffered I/O by splice.

• splice -> pipe -> splice_exact is not buffered which does not require error handling (and done at here).
• splice_exact -> pipe -> splice_exact is buffered which requires expected pipe size.
  According to GNU, buffering cannot be posix requirement while unbuffered can be posix requirement. So we can always use unbuffered one.
  Buffering is done to reduce syscalls, but it is just an overhead if one of in/output is already pipe.
  Also not useful for zero-copy since one splice call is mostly 1 MiB except for short read e.g. while sleep 1; do echo 1; done | (I don't think people want to deliberately remove responsiveness and can be used as a workaround for stdbuf issue).