> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
