On Mon 02-12-13 08:52:21, Dave Chinner wrote: <snip> > > I'm solving two cases here, one is holepunch vs fault for regular > > files. The other is truncate vs fault for XIP files, which is > > probably a little less rare. I think the same mechanism can be > > used when a filesystem is doing a defragment or otherwise moving > > blocks around on an XIP block device. > > Well, you kind of raised that as a secondary issue in passing, not > that it was the problem you actually need to solve. > > > Look, I'm not attached to the i_damage solution, > > but I do need something to protect against truncate vs fault on XIP. > > Fixing holepunch vs fault too just felt like the right thing to do. > > So, your real problem is that ext2-xip has a truncate vs fault race > because of a lack of a page lock to serialise page faults against > truncate. In fact, it appears to bypass the page cache completely > for both reads and writes (writes go directly to block device > memory), so it would seem that all the assumptions we've made about > serialisation on page locks throughout every filesystem are not > valid for XIP? Yeah, agreed. > Indeed, XIP could make use of the structures we already > have in the struct inode/address space to behave more like a normal > filesystem. We already use the mapping tree to store > per-page information that is used to serialise truncate vs page > faults, so why not make XIP do exactly the same thing? I believe that grabbing mmap_sem for writing during truncate (in case of ext2 around xip_truncate_page() & truncate_setsize() calls should do the trick. But I need to verify with lockdep that it doesn't introduce new locking problems. Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- 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
