Received-SPF: pass (google.com: domain of linux-kernel+bounces-11173-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Mon, 25 Dec 2023 22:50:17 +0100
From: 
	Ahelenia =?utf-8?Q?Ziemia=C5=84ska?= <nabijaczleweli@nabijaczleweli.xyz>
To: Askar Safin <safinaskar@gmail.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, 
	linux-man <linux-man@vger.kernel.org>, linux-s390@vger.kernel.org, linux-serial@vger.kernel.org, 
	netdev@vger.kernel.org, virtualization@lists.linux.dev
Subject: Re: Avoid unprivileged splice(file->)/(->socket) pipe exclusion
Message-ID: <d4ocnyfwlwqfdthubds6yshbn2xk67rsjh32glhkjtzcvq4x6k@tarta.nabijaczleweli.xyz>
References: <CAPnZJGCdr7pw80Pq38UacmxsbQAowmasPtFxQVCP+tm6Cj9pUg@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="elcjl7by3l7zvqng"
Content-Disposition: inline
In-Reply-To: <CAPnZJGCdr7pw80Pq38UacmxsbQAowmasPtFxQVCP+tm6Cj9pUg@mail.gmail.com>
User-Agent: NeoMutt/20231221-2-4202cf-dirty


--elcjl7by3l7zvqng
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 26, 2023 at 12:34:44AM +0300, Askar Safin wrote:
> In https://lore.kernel.org/lkml/CAHk-=3DwgG_2cmHgZwKjydi7=3DiimyHyN8aessn=
bM9XQ9ufbaUz9g@mail.gmail.com/
> 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.
>=20
> > 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-=3DwimmqG_wvSRtMiKPeGGDL816n65=
u=3DMq2+H3-=3DuM2U6FmA@mail.gmail.com/
> 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,

--elcjl7by3l7zvqng
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEfWlHToQCjFzAxEFjvP0LAY0mWPEFAmWJ+RcACgkQvP0LAY0m
WPEPHBAAprjcx1jdgNBsSoj62jLD0KLv+GkwIAVu1KVkI4xzk4wswel3/5uGs/KK
iyqj+OIxNaJsNUgc3Ro5fYFoK5R+zdLLBXMUujf8xa86XjWGYWYy3PnqpsuR00bJ
JrJ4ZHygilZU5WwVaz3S9HMV5tjBDLlLuHwkvaoBGuMQRdmfaI09hrrwB3ORbmEX
NAa0Al21p2raW/YN7SRsOiR49b6zNyK7t7tz3hNaDJiAI9x1rHhcUpoNi/0hyn0C
5LfBH+0J5hXlPgivvmHGeKggq9H1Y8610WUW9TVSlvxmOMxfOThoVGjV3c6JSzrB
4sgiqs5KVtB8Q0b7N157551R63FSnYHSmxObXixgQcuwew+e3gJ8HDt76YDm/ujc
TK/kzSmGrqwpENtSuO9OaBh0UjvI39EArPWQCiDhcHr70ICgxsHV0QWcUkRfWf9c
p3kNJorU0Lrf04dyS89p6pkA4rDFUj9eColK1CvFNgOLxG2IEyd2LFGqN5S58ZF6
Z0+6GY/qkJ+i/7qbCVEb0KGpPW9XEmPU0UFwA0PeaAhiAs9yAc+NbUyoIixQWFsu
HHFBnp4xcAwlLWrBWPgDSxv8nR1vhP0ti90/6FiHQhUtlK1T85YUHVkPJTn02iHD
1Q3ibe4SIWcc4GScMo9Ypz8i0j3Vc1qWvGM8p/PuxJlOIBCz3k4=
=y6v1
-----END PGP SIGNATURE-----

--elcjl7by3l7zvqng--