Re: [RFC][CFT] splice_read reworked

[CAI Qian <caiqian@redhat.com>]

> This usually happens when an application mixes mmap access and
> direct IO to the same file. The warning fires when the direct IO
> cannot invalidate the cached range after writeback (e.g. writeback
> raced with mmap app faulting and dirtying the page again), and hence
> results in the page cache containing stale data.  This warning fires
> when that happens, indicating to developers who get a bug report
> about data corruption that it's the userspace application that is
> the problem, not the filesystem. i.e the application is doing
> something we explicitly document they should not do:
> 
> $ man 2 open
> ....
>   O_DIRECT
> ....
>        Applications should avoid mixing O_DIRECT and normal I/O to
>        the same file, and especially to overlapping byte regions in
>        the  same  file.   Even  when  the filesystem  correctly
>        handles the coherency issues in this situation, overall I/O
>        throughput is likely to be slower than using either mode
>        alone.  Likewise, applications should avoid mixing mmap(2) of
>        files with direct I/O to the same files.
> 
> Splice should not have this problem if the IO path locking is
> correct, as both direct IO and splice IO use the same inode lock for
> exclusion. i.e. splice write should not be running at the same time
> as a direct IO read or write....
OK, so I assume that trinity is doing something that a proper userspace
application won't be doing which is fine, and there is nothing to worry
about from the kernel's perspective.

I just want to make sure there is no security implication here that a
non-privileged user could corrupt other users' data etc.
   CAI Qian