On Mon, 7 Jul 2008, Nick Piggin wrote: > And it isn't just a fuse problem is it? Other places can invalidate > and truncate pages which might be spliced into a pipe, can't they? Yes. There are several different problems here actually, and it's not completely clear how splice should handle them: Case 1: page is completely truncated while in the pipe Currently splice() will detect this and return a short read count on the splice-out. Which sounds sane, and consistent with the fact that a zero return value can happen on EOF. Case 2: page is partially truncated while in the pipe Splice doesn't detect this, and returns the contents of the whole page on splice-out, which will contain the zeroed-out part as well. This is not so nice, but other than some elaborate COW schemes, I don't see how this could be fixed. Case 3: page is invalidated while in the pipe This can happen on pages in the middle of the file, and splice-out can return a zero count. This is *BAD*, callers of splice really should be able to assume, that a zero return means EOF. Page invalidation (the invalidate_inode_pages2 kind) is done by only a few filesystems (FUSE, NFS, AFS, 9P), and by O_DIRECT hackery. So case 3 only affects these, and only fuse can be re-exported by nfsd (and that's only in -mm yet), hence this is very unlikely to be hit for any of the others. But it's bad despite being rare, because once it hits it can cause data corruption (like with fuse/nfsd) and could be very hard to debug. OK, case 2 could also cause corruption if caller is not expecting it. Splice is a cool concept, but it isn't easy to get the implementation right... Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
