[oech3]

Closes #15803 .
Note that this causes large performance drop:

> yes|tee /dev/null|pv>/dev/null
 133GiB 0:00:02 [66.8GiB/s]
> yes|tee-rw /dev/null|pv>/dev/null
10.1GiB 0:00:02 [5.09GiB/s]

[github-actions]

GNU testsuite comparison:

GNU test failed: tests/tee/tee. tests/tee/tee is passing on 'main'. Maybe you have to rebase?

[oech3]

Actually, this does not help. memfd must be truncated to 0 if writes contains a pipe (common situation) which made tee slower than read/write.

[oech3]

But it might worth to try to not reuse memfd.

[xtqqczze]

I think we can still have a fast path with multiple writers when:

• The file descriptor refers to a memfd.
• The producer applied the following seals: F_SEAL_WRITE, F_SEAL_GROW, and F_SEAL_SHRINK.

[oech3]

No (at least with if memfd was reused). Seals are unrelated at here since memfd is already provate resource (post-seals are actually unnecessary syscalls).

[xtqqczze]

I'm not suggesting applying seals necessarily. My point is that if these seals are already present, we can treat the source as immutable.

[oech3]

Post-sealing means it cannot be recycled. If we can keep fast-path by someway, I'll drop(memfd) after use instead of sealing.

[xtqqczze]

I’m saying we can check whether the producer has already applied the seals, not apply them ourselves.

[oech3]

It seems unrelated at here.

[oech3]

One of a option is post-sealing under debug build only to refuse wrong logic at tests.

Both of ftruncateing memfd and unreusing memfd (needed to detach page caches) were slower than read/write anyway.

[oech3]

I think there is no fast-path for multiple outputs wihout using infinite RAM.
We can reuse memfd if writers does not contain pipe, or restrict fast-path to 1st 1 MiB, but it is too limited, or read/write is faster.
Closing. I'll open a simple cleanup PR when CI is green.