On Thu, Sep 8, 2016 at 8:29 AM, CAI Qian <caiqian@xxxxxxxxxx> wrote:
> Right. FYI, revert the commit below fixes the regression,
>
> 8d02076 : ->splice_write() via ->write_iter()
I guess you didn't actually revert that, because so much else has
changed. So you just tested the pre- and post- state of that commit?
It does look like that commit is just buggy, exactly because XSF was
the only user of -generic_file_splice_write() in order to be able to
do the filesystem locks *before* taking the pipe lock.
Al? I wonder if we could just re-introduce xfs_file_splice_write()
(except with the modern iter-based interface)?
Looking at not holding the pipe lock, that really does seem very bad,
because it would require us to:
(a) play the ref-count games with each page
(b) make concurrent splice writers have very subtle semantics
I'm not sure (b) is a big issue, because concurrent splice writers
already have random ordering, but at least right now they'd have
non-overlapping data accesses rather than possibly splicing the same
data twice (and some data not at all).
The basic issue with splice and xfs is that right now our splice
interface *forces*:
- generic_file_splice_read() when called by a filesystem will take
the filesystem locks *first*, and the pipe lock second (ie
xfs_file_splice_read)
- iter_file_splice_write() forces the reverse ordering.
So it really is our splice helpers that do things in fundamentally the
wrong order.
Other filesystems don't seem to have that extra filesystem lock that shows this.
Ideas?
Linus
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
