Re: hole-punch vs fault

[Jan Kara <jack@suse.cz>]

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@suse.cz>
SUSE Labs, CR