[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20230627120043.152df5dd@canb.auug.org.au>
Date: Tue, 27 Jun 2023 12:00:43 +1000
From: Stephen Rothwell <sfr@...b.auug.org.au>
To: David Miller <davem@...emloft.net>
Cc: Jens Axboe <axboe@...nel.dk>, David Howells <dhowells@...hat.com>,
Jakub Kicinski <kuba@...nel.org>,
Networking <netdev@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: manual merge of the block tree with the net-next
tree
Hi all,
On Tue, 13 Jun 2023 12:59:39 +1000 Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>
> Today's linux-next merge of the block tree got a conflict in:
>
> fs/splice.c
>
> between commit:
>
> 2bfc66850952 ("splice, net: Add a splice_eof op to file-ops and socket-ops")
>
> from the net-next tree and commit:
>
> 6a3f30b8bdb2 ("splice: Make do_splice_to() generic and export it")
>
> from the block tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc fs/splice.c
> index 67ddaac1f5c5,2420ead610a7..000000000000
> --- a/fs/splice.c
> +++ b/fs/splice.c
> @@@ -969,23 -841,24 +937,35 @@@ static long do_splice_from(struct pipe_
> return out->f_op->splice_write(pipe, out, ppos, len, flags);
> }
>
> +/*
> + * Indicate to the caller that there was a premature EOF when reading from the
> + * source and the caller didn't indicate they would be sending more data after
> + * this.
> + */
> +static void do_splice_eof(struct splice_desc *sd)
> +{
> + if (sd->splice_eof)
> + sd->splice_eof(sd);
> +}
> +
> - /*
> - * Attempt to initiate a splice from a file to a pipe.
> + /**
> + * vfs_splice_read - Read data from a file and splice it into a pipe
> + * @in: File to splice from
> + * @ppos: Input file offset
> + * @pipe: Pipe to splice to
> + * @len: Number of bytes to splice
> + * @flags: Splice modifier flags (SPLICE_F_*)
> + *
> + * Splice the requested amount of data from the input file to the pipe. This
> + * is synchronous as the caller must hold the pipe lock across the entire
> + * operation.
> + *
> + * If successful, it returns the amount of data spliced, 0 if it hit the EOF or
> + * a hole and a negative error code otherwise.
> */
> - static long do_splice_to(struct file *in, loff_t *ppos,
> - struct pipe_inode_info *pipe, size_t len,
> - unsigned int flags)
> + long vfs_splice_read(struct file *in, loff_t *ppos,
> + struct pipe_inode_info *pipe, size_t len,
> + unsigned int flags)
> {
> unsigned int p_space;
> int ret;
> @@@ -1081,9 -959,9 +1070,9 @@@ ssize_t splice_direct_to_actor(struct f
> size_t read_len;
> loff_t pos = sd->pos, prev_pos = pos;
>
> - ret = do_splice_to(in, &pos, pipe, len, flags);
> + ret = vfs_splice_read(in, &pos, pipe, len, flags);
> if (unlikely(ret <= 0))
> - goto out_release;
> + goto read_failure;
>
> read_len = ret;
> sd->total_len = read_len;
This is now a conflict between the net-next tree and Linus' tree.
--
Cheers,
Stephen Rothwell
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists