On Tue, Dec 26, 2023 at 12:34:44AM +0300, Askar Safin wrote: > In https://lore.kernel.org/lkml/CAHk-=wgG_2cmHgZwKjydi7=iimyHyN8aessnbM9XQ9ufbaUz9g@xxxxxxxxxxxxxx/ > Linus said: > > I have grown to pretty much hate > > splice() over the years, just because it's been a constant source of > > sorrow in so many ways. > > > It's just that it was never as lovely and as useful as it promised to > > be. So I'd actually be more than happy to just say "let's decommission > > splice entirely, just keeping the interfaces alive for backwards > > compatibility" > So probably we should do this as Linus suggested? I. e. fully remove > splice by replacing it with trivial read-write? I am doing just like he suggested downthread of my original report, in https://lore.kernel.org/linux-fsdevel/CAHk-=wimmqG_wvSRtMiKPeGGDL816n65u=Mq2+H3-=uM2U6FmA@xxxxxxxxxxxxxx/ > But it is possible that we need to just bite the bullet and say > "copy_splice_read() needs to use a non-blocking kiocb for the IO". I see it post-dates the thing you cited, which naturally makes it more valid, and it directly references this particular issue, instead of an annoying data corruption one. This whole series effectively amounts to three patches (delete splice_* form ttys, make IPC splice_read nonblocking when lock is held, make IPC splice_write nonblocking when lock is held) just the latter two to thirty implementations of the same funxion. This is hardly reason to kill an interface that doubles the performance of a very common operation IMO. Honestly, no-one would probably run into this in another decade if just the splice_* deletion from ttys was implemented; this is just thoroughness to a fault since you can spin this as a security issue, really. Best,
Attachment:
signature.asc
Description: PGP signature
