[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJfpegstr2CwC2ZL4-y_bAjS3hqF_vta5e4XQneJYmxz9rhVpA@mail.gmail.com>
Date: Mon, 24 Jul 2023 15:55:21 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: David Howells <dhowells@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Matthew Wilcox <willy@...radead.org>,
Matt Whitlock <kernel@...twhitlock.name>,
netdev@...r.kernel.org, Dave Chinner <david@...morbit.com>,
Jens Axboe <axboe@...nel.dk>, linux-fsdevel@...ck.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Christoph Hellwig <hch@....de>, linux-fsdevel@...r.kernel.org
Subject: Re: [RFC PATCH 1/4] splice: Fix corruption of spliced data after
splice() returns
On Mon, 24 Jul 2023 at 11:44, David Howells <dhowells@...hat.com> wrote:
>
> Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>
> > > So what's the API that provides the semantics of _copying_?
> >
> > It's called "read()" and "write()".
>
> What about copy_file_range()? That seems to fall back to splicing if not
> directly implemented by the filesystem. It looks like the manpage for that
> needs updating too - or should that actually copy?
Both source and destination of copy_file_range() are regular files and
do_splice_direct() is basically equivalent to write(dest, mmap of
source), no refd buffers remain beyond the end of the syscall. What
is it that should be updated in the manpage?
Thanks,
Miklos
Powered by blists - more mailing lists