From: Al Viro <viro@zeniv.linux.org.uk>
To: David Howells <dhowells@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>,
Christoph Hellwig <hch@infradead.org>,
Matthew Wilcox <willy@infradead.org>, Jan Kara <jack@suse.cz>,
Jeff Layton <jlayton@kernel.org>,
David Hildenbrand <david@redhat.com>,
Jason Gunthorpe <jgg@nvidia.com>,
Logan Gunthorpe <logang@deltatee.com>,
Hillf Danton <hdanton@sina.com>,
Christian Brauner <brauner@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Christoph Hellwig <hch@lst.de>,
John Hubbard <jhubbard@nvidia.com>
Subject: Re: [PATCH v18 09/15] iov_iter: Kill ITER_PIPE
Date: Thu, 20 Apr 2023 23:22:31 +0100 [thread overview]
Message-ID: <20230420222231.GT3390869@ZenIV> (raw)
In-Reply-To: <20230314220757.3827941-10-dhowells@redhat.com>
On Tue, Mar 14, 2023 at 10:07:51PM +0000, David Howells wrote:
> The ITER_PIPE-type iterator was only used for generic_file_splice_read(),
> but that has now been switched to either pull pages directly from the
> pagecache for buffered file splice-reads or to use ITER_BVEC instead for
> O_DIRECT file splice-reads. This leaves ITER_PIPE unused - so remove it.
Wonderful, except that now you've got duplicates of ->read_iter() for
everyone who wants zero-copy on ->splice_read() ;-/
I understand the attraction of arbitrary seeks on those suckers; ITER_PIPE
is a massive headache in that respect. But I really don't like what your
approach trades it for.
And you are nowhere near done - consider e.g. NFS. Mainline has it
feed ITER_PIPE to nfs_file_read(), which does call generic_file_read_iter() -
after
result = nfs_revalidate_mapping(inode, iocb->ki_filp->f_mapping);
Sure, you can add nfs_file_splice_read() that would do what nfs_file_read()
does, calling filemap_spice_read() instead of generic_file_read_iter().
Repeat the same for ocfs2 (locking of its own). And orangefs. And
XFS (locking, again). And your own AFS, while we are at it. Et sodding
cetera - *everything* that uses generic_file_splice_read() with
->read_iter other than generic_file_read_iter() needs review and,
quite likely, a ->splice_read() instance of its own.
next prev parent reply other threads:[~2023-04-20 22:23 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-14 22:07 [PATCH v18 00/15] splice, block: Use page pinning and kill ITER_PIPE David Howells
2023-03-14 22:07 ` [PATCH v18 01/15] splice: Clean up direct_splice_read() a bit David Howells
2023-03-14 22:07 ` [PATCH v18 02/15] splice: Make do_splice_to() generic and export it David Howells
2023-03-14 22:07 ` [PATCH v18 03/15] shmem: Implement splice-read David Howells
2023-03-14 23:39 ` Linus Torvalds
2023-03-14 22:07 ` [PATCH v18 04/15] overlayfs: " David Howells
2023-03-14 22:07 ` [PATCH v18 05/15] coda: " David Howells
2023-03-14 22:07 ` [PATCH v18 06/15] tty, proc, kernfs, random: Use direct_splice_read() David Howells
2023-03-14 22:07 ` [PATCH v18 07/15] splice: Do splice read from a file without using ITER_PIPE David Howells
2023-03-14 22:07 ` [PATCH v18 08/15] cifs: Use generic_file_splice_read() David Howells
2023-03-14 22:52 ` Paulo Alcantara
2023-03-14 22:07 ` [PATCH v18 09/15] iov_iter: Kill ITER_PIPE David Howells
2023-04-20 22:22 ` Al Viro [this message]
2023-04-20 22:36 ` Al Viro
2023-04-21 1:11 ` Al Viro
2023-04-21 2:25 ` Al Viro
2023-03-14 22:07 ` [PATCH v18 10/15] iomap: Don't get an reference on ZERO_PAGE for direct I/O block zeroing David Howells
2023-03-14 22:07 ` [PATCH v18 11/15] block: Fix bio_flagged() so that gcc can better optimise it David Howells
2023-03-14 22:07 ` [PATCH v18 12/15] block: Replace BIO_NO_PAGE_REF with BIO_PAGE_REFFED with inverted logic David Howells
2023-03-14 22:07 ` [PATCH v18 13/15] block: Add BIO_PAGE_PINNED and associated infrastructure David Howells
2023-03-14 22:07 ` [PATCH v18 14/15] block: Convert bio_iov_iter_get_pages to use iov_iter_extract_pages David Howells
2023-03-14 22:07 ` [PATCH v18 15/15] block: convert bio_map_user_iov " David Howells
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=20230420222231.GT3390869@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=david@redhat.com \
--cc=dhowells@redhat.com \
--cc=hch@infradead.org \
--cc=hch@lst.de \
--cc=hdanton@sina.com \
--cc=jack@suse.cz \
--cc=jgg@nvidia.com \
--cc=jhubbard@nvidia.com \
--cc=jlayton@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=logang@deltatee.com \
--cc=torvalds@linux-foundation.org \
--cc=willy@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.