Message ID | 20230214171330.2722188-1-dhowells@redhat.com (mailing list archive) |
---|---|
Headers | show |
Series | iov_iter: Improve page extraction (pin or just list) | expand |
Hi Jens, If you decide not to take my patches in this merge window, would you have any objection to my patches 1-3 and 10-11 in this series going through Steve French's cifs tree so that he can take my cifs iteratorisation patches? Patches 1-3 would add filemap_splice_read() and direct_splice_read(), but not connect them up to anything and 10-11 would add iov_iter_extract_pages(). I can then give Steve a patch to make cifs use them as part of my patches for that. This would only affect cifs. See my iov-cifs branch: https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=iov-cifs for an example of how this would look. David
David Howells <dhowells@redhat.com> wrote:
> This would only affect cifs.
Actually, that's not quite true: it changes the flags argument to
iov_iter_get_pages*().
David
On 2/14/23 3:56 PM, David Howells wrote: > Hi Jens, > > If you decide not to take my patches in this merge window, would you have any > objection to my patches 1-3 and 10-11 in this series going through Steve > French's cifs tree so that he can take my cifs iteratorisation patches? > > Patches 1-3 would add filemap_splice_read() and direct_splice_read(), but not > connect them up to anything and 10-11 would add iov_iter_extract_pages(). I > can then give Steve a patch to make cifs use them as part of my patches for > that. > > This would only affect cifs. See my iov-cifs branch: > > https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=iov-cifs > > for an example of how this would look. Let's update the branch and see how it goes... If there's more fallout, then let's make a fallback plan for the first few.
Jens Axboe <axboe@kernel.dk> wrote: > Let's update the branch and see how it goes... If there's more fallout, then > let's make a fallback plan for the first few. I forgot to export the new functions, as Steve found out. Fix attached. David --- splice: Export filemap/direct_splice_read() filemap_splice_read() and direct_splice_read() should be exported. Signed-off-by: David Howells <dhowells@redhat.com> cc: Steve French <sfrench@samba.org> cc: Jens Axboe <axboe@kernel.dk> cc: Christoph Hellwig <hch@lst.de> cc: Al Viro <viro@zeniv.linux.org.uk> cc: David Hildenbrand <david@redhat.com> cc: John Hubbard <jhubbard@nvidia.com> cc: linux-cifs@vger.kernel.org cc: linux-mm@kvack.org cc: linux-block@vger.kernel.org cc: linux-fsdevel@vger.kernel.org --- fs/splice.c | 1 + mm/filemap.c | 1 + 2 files changed, 2 insertions(+) diff --git a/fs/splice.c b/fs/splice.c index 4c6332854b63..928c7be2f318 100644 --- a/fs/splice.c +++ b/fs/splice.c @@ -373,6 +373,7 @@ ssize_t direct_splice_read(struct file *in, loff_t *ppos, kfree(bv); return ret; } +EXPORT_SYMBOL(direct_splice_read); /** * generic_file_splice_read - splice data from file to a pipe diff --git a/mm/filemap.c b/mm/filemap.c index 8c7b135c8e23..570f86578f7c 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -2969,6 +2969,7 @@ ssize_t filemap_splice_read(struct file *in, loff_t *ppos, return total_spliced ? total_spliced : error; } +EXPORT_SYMBOL(filemap_splice_read); static inline loff_t folio_seek_hole_data(struct xa_state *xas, struct address_space *mapping, struct folio *folio,
David Howells <dhowells@redhat.com> wrote: > Jens Axboe <axboe@kernel.dk> wrote: > > > Let's update the branch and see how it goes... If there's more fallout, then > > let's make a fallback plan for the first few. > > I forgot to export the new functions, as Steve found out. Fix attached. That said, nothing in your tree that calls these functions directly can be built as a module, so this can be left to the cifs tree for now. David
On Wed, Feb 15, 2023 at 08:07:58AM +0000, David Howells wrote: > return total_spliced ? total_spliced : error; > } > +EXPORT_SYMBOL(filemap_splice_read); EXPORT_SYMBOL_GPL for filemap internals, please.
And who is using filemap_splice_read directly anyway? I can't find a modular user in any of the branches.
Christoph Hellwig <hch@infradead.org> wrote: > And who is using filemap_splice_read directly anyway? I can't find a > modular user in any of the branches. Fair point. I have a subset of the patches on my iov-cifs branch that doesn't make the change to generic_file_read_splice(), but rather does that bit in cifs.ko - that does require access to filemap_splice_read(). David