From: Al Viro <viro@zeniv.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Christoph Hellwig <hch@lst.de>,
Johannes Berg <johannes@sipsolutions.net>,
Oliver Giles <ohw.giles@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: Splicing to/from a tty
Date: Thu, 21 Jan 2021 01:45:28 +0000 [thread overview]
Message-ID: <20210121014528.GG740243@zeniv-ca> (raw)
In-Reply-To: <CAHk-=whWGwcZXpqDFv-j2fcChtT1jE0ZMFCmQHp3BrSkp+XZ6A@mail.gmail.com>
On Wed, Jan 20, 2021 at 05:04:17PM -0800, Linus Torvalds wrote:
> The whole point of O_APPEND is that the position shouldn't matter.
>
> And the whole point of "pwrite()" is that you specify a position.
>
> So the two just do not go together - although we may have legacy
> issues, of course.
Our pwrite(2):
BUGS
POSIX requires that opening a file with the O_APPEND flag
should have no effect on the location at which pwrite() writes
data. However, on Linux, if a file is opened with O_APPEND,
pwrite() appends data to the end of the file, regardless of
the value of offset.
POSIX pwrite(2):
The pwrite() function shall be equivalent to write(), except that
it writes into a given position and does not change the file offset
(regardless of whether O_APPEND is set). The first three arguments
to pwrite() are the same as write() with the addition of a fourth
argument offset for the desired position inside the file. An attempt
to perform a pwrite() on a file that is incapable of seeking shall
result in an error.
I don't believe that we could change behaviour of our pwrite(2) without
breaking userland, even if we wanted to. It's been that way since
2.1.60 when pwrite() had been first introduced - 23 years ago is more
than enough to have it cast in stone. We do allow pwrite(2) with O_APPEND
and on such descriptors it acts like write(2) on the same.
> Now, splice() is able to do *both* write() and pwrite(), because
> unlike pwrite() it doesn't take a "pos" argument, it takes a _pointer_
> to pos. So with a NULL pointer, it's like read/write, and with a
> non-NULL pointer it is like pread/pwrite.
>
> So I do think that "splice with non-NULL off_out and O_APPEND" should
> cause an error in general.
splice() triggers an error for seekable destination with O_APPEND and
with NULL off_out. Same for splice() to socket with
fcntl(sock_fd, F_SETFL, O_APPEND);
done first.
> Honestly, I don't think it's a huge deal. O_APPEND isn't that
> interesting, but I do hope that if we allow O_APPEND and a file
> position, then O_APPEND always overrides it.
It does, when it is allowed.
next prev parent reply other threads:[~2021-01-21 3:03 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-16 7:35 Splicing to/from a tty Oliver Giles
2021-01-16 16:46 ` Johannes Berg
2021-01-17 6:12 ` Oliver Giles
2021-01-18 8:53 ` Christoph Hellwig
2021-01-18 8:58 ` Johannes Berg
2021-01-18 19:26 ` Linus Torvalds
2021-01-18 19:45 ` Al Viro
2021-01-18 19:49 ` Linus Torvalds
2021-01-18 19:56 ` Al Viro
2021-01-24 19:11 ` Linus Torvalds
2021-01-25 9:16 ` [PATCH] fs/pipe: allow sendfile() to pipe again Johannes Berg
2021-01-25 10:16 ` Christoph Hellwig
2021-01-25 20:34 ` Linus Torvalds
2021-01-26 6:07 ` Splicing to/from a tty Al Viro
2021-01-26 6:08 ` [PATCH 1/3] do_splice_to(): move the logics for limiting the read length in Al Viro
2021-01-26 6:09 ` [PATCH 2/3] take the guts of file-to-pipe splice into a helper function Al Viro
2021-01-26 6:09 ` [PATCH 3/3] teach sendfile(2) to handle send-to-pipe directly Al Viro
2021-01-26 18:57 ` Linus Torvalds
2021-01-26 19:33 ` Al Viro
2021-01-26 18:49 ` Splicing to/from a tty Linus Torvalds
2021-01-26 19:42 ` Al Viro
2021-01-18 19:34 ` Al Viro
2021-01-18 19:46 ` Linus Torvalds
2021-01-18 19:54 ` Al Viro
2021-01-20 16:26 ` Al Viro
2021-01-20 19:11 ` Al Viro
2021-01-20 19:27 ` Linus Torvalds
2021-01-20 22:25 ` David Laight
2021-01-20 23:02 ` Al Viro
2021-01-20 23:14 ` Al Viro
2021-01-20 23:40 ` Linus Torvalds
2021-01-21 0:38 ` Al Viro
2021-01-21 1:04 ` Linus Torvalds
2021-01-21 1:45 ` Al Viro [this message]
2021-01-21 3:38 ` Linus Torvalds
2021-01-21 6:05 ` Willy Tarreau
2021-01-21 8:04 ` Johannes Berg
2021-01-21 10:08 ` David Laight
2021-01-18 8:16 ` Christoph Hellwig
2021-01-18 19:36 ` Linus Torvalds
2021-01-18 20:24 ` Linus Torvalds
2021-01-18 21:35 ` Linus Torvalds
2021-01-18 21:54 ` Linus Torvalds
2021-01-18 22:03 ` Linus Torvalds
2021-01-18 22:20 ` Linus Torvalds
2021-01-19 1:38 ` Linus Torvalds
2021-01-19 11:53 ` Greg Kroah-Hartman
2021-01-19 16:56 ` Robert Karszniewicz
2021-01-19 17:10 ` Robert Karszniewicz
2021-01-19 22:09 ` Oliver Giles
2021-01-19 17:25 ` Linus Torvalds
2021-01-19 20:24 ` Linus Torvalds
2021-01-19 20:38 ` Christoph Hellwig
2021-01-20 1:25 ` Oliver Giles
2021-01-20 4:44 ` Linus Torvalds
2021-01-20 8:15 ` Oliver Giles
2021-01-21 1:18 ` tty splice branch (was "Re: Splicing to/from a tty") Linus Torvalds
2021-01-21 8:44 ` Greg Kroah-Hartman
2021-01-21 8:50 ` Jiri Slaby
2021-01-21 8:58 ` Jiri Slaby
2021-01-21 17:52 ` Linus Torvalds
2021-01-21 8:58 ` Greg Kroah-Hartman
2021-01-21 17:03 ` Splicing to/from a tty Robert Karszniewicz
2021-01-21 18:43 ` Linus Torvalds
2021-01-19 11:52 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210121014528.GG740243@zeniv-ca \
--to=viro@zeniv.linux.org.uk \
--cc=gregkh@linuxfoundation.org \
--cc=hch@lst.de \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=ohw.giles@gmail.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).