Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Subject: Splicing to/from a tty
From:   "Oliver Giles" <ohw.giles@gmail.com>
To:     <linux-kernel@vger.kernel.org>
Cc:     "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
        "Christoph Hellwig" <hch@lst.de>
Date:   Sat, 16 Jan 2021 20:35:41 +1300
Message-Id: <C8KER7U60WXE.25UFD8RE6QZQK@oguc>
Precedence: bulk

Commit 36e2c7421f02 (fs: don't allow splice read/write without explicit ops=
) broke my userspace application which talks to an SSL VPN by splice()ing b=
etween "openssl s_client" and "pppd". The latter operates over a pty, and s=
ince that commit there is no fallback for splice()ing between a pipe and a =
pty, or any tty for that matter.

The above commit mentions switching them to the iter ops and using generic_=
file_splice_read. IIUC, this would require implementing iter ops also on th=
e line disciplines, which sounds pretty disruptive.

For my case, I attempted to instead implement splice_write and splice_read =
in tty_fops; I managed to get splice_write working calling ld->ops->write, =
but splice_read is not so simple because the tty_ldisc_ops read method expe=
cts a userspace buffer. So I cannot see how to implement this without eithe=
r (a) using set_fs, or (b) implementing iter ops on all line disciplines.

Is splice()ing between a tty and a pipe worth supporting at all? Not a big =
deal for my use case at least, but it used to work.