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