On Wednesday, 28 June 2023 02:30:50 EDT, David Howells wrote:
Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
Expected behavior:
Punching holes in a file after splicing pages out of that
file into a pipe
should not corrupt the spliced-out pages in the pipe buffer.
I think this bit is the key. Why would this be the expected behaviour?
Why? Because SPLICE_F_MOVE exists. Even though that flag is a no-op as of
Linux 2.6.21, its existence implies that calling splice() *without*
specifying SPLICE_F_MOVE performs a *copy*. The kernel is, of course, free
*not* to copy pages in pursuit of better performance, but it must behave as
though it did copy unless SPLICE_F_MOVE is specified, in which case
userspace is explicitly acknowledging that subsequent modification of the
spliced pages may impact the spliced data. Effectively, SPLICE_F_MOVE is a
promise by userspace that the moved pages will not be subsequently
modified, and if they are, then all bets are off.
In other words, the currently implemented behavior is appropriate for
SPLICE_F_MOVE, but it is not appropriate for ~SPLICE_F_MOVE.
