> So I'm not sure why we'd need to care?
>
> The thing is, if the splicer and the hole puncher aren't synchronized,
> then there is by definition no "before/after" point.
>
> The splice data may be "stale" in the sense that we look at the page
> after the hole punch has happened and the page no longer has a
> ->mapping associated with it, but it is equally valid to treat that as
> just a case of "the read happened before the hole punch".
>
> Put another way: it's not wrong to use the ostensibly "stale" data, it
> just means that the splice acts as if the IO had happened before the
> data became stale.
We care because __generic_file_splice_read() is playing fast and loose with
pagecache. It gathers pointers to pages and *then* issues ->readpage() on
them. Without any protection against hole-punching. That's actually one
more example of the reasons why we really ought to just call ->read_iter()
and let the regular fs logics take care of exclusion. pipe lock is needed
only to pass the pages we'd grabbed (from page cache) or allocated (for
copy_to_iter() callers, like e.g. DAX) into the pipe itself.
|