mbox series

[v2,0/4] iov_iter: Adjust styling/location of new splice functions

Message ID 20230213153301.2338806-1-dhowells@redhat.com (mailing list archive)
Headers show
Series iov_iter: Adjust styling/location of new splice functions | expand

Message

David Howells Feb. 13, 2023, 3:32 p.m. UTC
Hi Jens, Al, Christoph,

Here are patches to make some changes that Christoph requested[1] to the
new generic file splice functions that I implemented[2].  Apart from one
functional change, they just altering the styling and move one of the
functions to a different file:

 (1) Rename the main functions:

	generic_file_buffered_splice_read() -> filemap_splice_read()
	generic_file_direct_splice_read()   -> direct_splice_read()

 (2) Abstract out the calculation of the location of the head pipe buffer
     into a helper function in linux/pipe_fs_i.h.

 (3) Use init_sync_kiocb() in filemap_splice_read().

     This is where the functional change is.  Some kiocb fields are then
     filled in where they were set to 0 before, including setting ki_flags
     from f_iocb_flags.  I've filtered out IOCB_NOWAIT as the function is
     supposed to be synchronous.

 (4) Move filemap_splice_read() to mm/filemap.c.  filemap_get_pages() can
     then be made static again.

I've pushed the patches here also:

	https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=iov-extract-3

I've also updated worked the changes into the commits on my iov-extract
branch if that would be preferable, though that means Jens would need to
update his for-6.3/iov-extract again.

David

Link: https://lore.kernel.org/r/Y+n0n2UE8BQa/OwW@infradead.org/ [1]
Link: https://lore.kernel.org/r/20230207171305.3716974-1-dhowells@redhat.com/ [2]

Changes
=======
ver #2)
 - Don't attempt to filter IOCB_* flags in filemap_splice_read().

Link: https://lore.kernel.org/r/20230213134619.2198965-1-dhowells@redhat.com/ # v1

David Howells (4):
  splice: Rename new splice functions
  splice: Provide pipe_head_buf() helper
  splice: Use init_sync_kiocb() in filemap_splice_read()
  splice: Move filemap_read_splice() to mm/filemap.c

 fs/splice.c               | 146 ++------------------------------------
 include/linux/pagemap.h   |   2 -
 include/linux/pipe_fs_i.h |  20 ++++++
 include/linux/splice.h    |   4 ++
 mm/filemap.c              | 137 +++++++++++++++++++++++++++++++++--
 5 files changed, 162 insertions(+), 147 deletions(-)

Comments

Jens Axboe Feb. 13, 2023, 5:04 p.m. UTC | #1
On 2/13/23 8:32 AM, David Howells wrote:
> Hi Jens, Al, Christoph,
> 
> Here are patches to make some changes that Christoph requested[1] to the
> new generic file splice functions that I implemented[2].  Apart from one
> functional change, they just altering the styling and move one of the
> functions to a different file:
> 
>  (1) Rename the main functions:
> 
> 	generic_file_buffered_splice_read() -> filemap_splice_read()
> 	generic_file_direct_splice_read()   -> direct_splice_read()
> 
>  (2) Abstract out the calculation of the location of the head pipe buffer
>      into a helper function in linux/pipe_fs_i.h.
> 
>  (3) Use init_sync_kiocb() in filemap_splice_read().
> 
>      This is where the functional change is.  Some kiocb fields are then
>      filled in where they were set to 0 before, including setting ki_flags
>      from f_iocb_flags.  I've filtered out IOCB_NOWAIT as the function is
>      supposed to be synchronous.
> 
>  (4) Move filemap_splice_read() to mm/filemap.c.  filemap_get_pages() can
>      then be made static again.
> 
> I've pushed the patches here also:
> 
> 	https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=iov-extract-3
> 
> I've also updated worked the changes into the commits on my iov-extract
> branch if that would be preferable, though that means Jens would need to
> update his for-6.3/iov-extract again.

Honestly, it's getting tight on timing at this point, and there's also
a crash report from today:

https://lore.kernel.org/linux-block/Y+pdHFFTk1TTEBsO@makrotopia.org/

I think we'd be better off folding in this series and then potentially
pushing this series to 6.4 rather than 6.3.