On Thu, 14 Aug 2025 at 10:28, Chunsheng Luo <luochunsheng@xxxxxxxx> wrote:
>
> On Wed, Aug 13, 2025 at 5:11 PM Miklos Szeredi wrote:
> > @@ -1624,8 +1629,7 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
> > * to splicing from input file, while file_start_write() is held on
> > * the output file on a different sb.
> > */
> > - ret = do_splice_direct(file_in, &pos_in, file_out, &pos_out,
> > - min_t(size_t, len, MAX_RW_COUNT), 0);
> > + ret = do_splice_direct(file_in, &pos_in, file_out, &pos_out, len, 0);
> > done:
> > if (ret > 0) {
> > fsnotify_access(file_in);
>
> There is no problem with submission, but I have a doubt in the call chain:
> `do_splice_direct -> do_splice_direct_actor:`
> static ssize_t do_splice_direct_actor(struct file *in, loff_t *ppos,
> struct file *out, loff_t *opos,
> size_t len, unsigned int flags,
> splice_direct_actor *actor)
> {
> struct splice_desc sd = {
> .len = len, //unsigned int len
> .total_len = len,
> ...
> };
>
> The len member in the struct splice_desc is of type unsigned int.
> The assignment here may cause truncation, but in reality, this len
> won't be used. Can we directly delete it?
Yes, looks safe. Goes back to commit introducing splice_desc
c66ab6fa705e ("splice: abstract out actor data").
Thanks,
Miklos
