On Mon, Mar 28, 2016 at 08:25:46PM -0800, Kent Overstreet wrote: > Bit of previous discussion: > http://thread.gmane.org/gmane.linux.file-systems/101201/ > > The underlying issue is that we have no mechanism for invalidating a range of > the pagecache and then _keeping it invalidated_ while we Do Stuff. > > The fallocate INSERT_RANGE/COLLAPSE_RANGE situation seems likely to be worse > than I initially thought. I've been digging into this in the course of bcachefs > testing - I was hitting assertions that meant state hanging off the page cache > (in this case, allocation information, i.e. whether we needed to reserve space > on write) was inconsistent with the btree in writepages(). > > Well, bcachefs isn't the only filesystem that hangs additional state off the > pagecache, and the situation today is that an unpriviliged user can cause > inconsistencies there by just doing buffered reads concurrently with > INSERT_RANGE/COLLAPSE_RANGE. I highly highly doubt this is an issue of just > "oops, you corrupted your file because you were doing stupid stuff" - who knows > what internal invariants are getting broken here, and I don't particularly care > to find out. I'd like to see a test case for this. Concurrent IO and/or page faults should not run at the same as fallocate on XFS. Hence I'd like to see the test cases that demonstrate buffered reads are causing corruption during insert/collapse range operations. We use the same locking strategy for fallocate as we use for truncate and all the other internal extent manipulation operations, so if there's something wrong, we need to fix it. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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
