xfs_file_splice_read: possible circular locking dependency detected

[Al Viro]

> 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.