Re: hole-punch vs fault

[Matthew Wilcox <matthew@wil.cx>]

On Fri, Nov 29, 2013 at 09:12:46AM +1100, Dave Chinner wrote:
> Indeed, we've already discussed this at length - if we are going to
> introduce a new method of synchronisation between mmap and
> holepunch, then we cannot ignore all the other mmap vs IO
> synchronisation problems we have that are caused by the same issue.
> Hacking workarounds into the holepunch/mmap paths is not a robust or
> maintainable solution.

This isn't hacking in a workaround.  This is a solution to the problem
that assumes holepunches are rare, and it's OK to make the fault path retry
if a holepunch happened.  I agree it needs to be documented and the exact
details of what is protected by i_damaged_mutex needs to be clear.

> 	a) it is a entire file lock and truncate/holepunch do not
> 	   affect the entire scope of the file. i.e. there is no
> 	   reason why holepunch cannot run concurrently with IO if
> 	   they are to different ranges of a file.

Yes, if we care about the scalability of truncate and holepunch.  I really
don't think that's an important workload.

> 	b) it increases the struct inode by at least 5%. If we are
> 	   going to increase the inode by that much, we better make
> 	   sure we solve more than one isolated, relatively rare
> 	   corner case behaviour.

About 7% (568 -> 608 bytes) with my .config (SMP, SPIN_ON_OWNER,
!DEBUG_MUTEXES, !DEBUG_LOCK_ALLOC).  I rearranged the order (thanks,
pahole!) to put i_damage in the hole created by private_lock.

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

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."