[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <2XFP6S.GINKQ8IKAA1W1@gmail.com>
Date: Thu, 04 Jan 2024 10:34:14 +1300
From: Oliver Giles <ohw.giles@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Jiri Slaby <jirislaby@...nel.org>, Ahelenia ZiemiaĆska
<nabijaczleweli@...ijaczleweli.xyz>, Jens Axboe <axboe@...nel.dk>,
Christian Brauner <brauner@...nel.org>, Alexander Viro
<viro@...iv.linux.org.uk>, linux-fsdevel@...r.kernel.org, Greg Kroah-Hartman
<gregkh@...uxfoundation.org>, linux-kernel@...r.kernel.org,
linux-serial@...r.kernel.org
Subject: Re: [PATCH v2 08/11] tty: splice_read: disable
On Wed, Jan 3 2024 at 11:14:59 -08:00:00, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> It's some annoying SSL VPN thing that splices to pppd:
>
> https://lore.kernel.org/all/C8KER7U60WXE.25UFD8RE6QZQK@oguc/
I'm happy to report that that particular SSL VPN tool is no longer
around.
And it had anyway grown a fall-back-to-read/write in case splice()
fails.
So at least from my perspective, no objections to splice-to-tty going
away
altogether.
> and I'd be happy to try to limit splice to tty's to maybe just the one
> case that pppd uses.
To be exact, pppd is just providing a pty with which other (now all
extinct?)
applications can do nefarious things.
> Maybe that VPN thing already has the pty in non-blocking mode, for
> example, and we could make the tty splicing fail for any blocking op?
FWIW, the SSL VPN tool did indeed have the pty in non-blocking mode.
Oliver
Powered by blists - more mailing lists