On 09/07/22 10:22, Sven Schnelle wrote: > Mike Kravetz <mike.kravetz@xxxxxxxxxx> writes: > > > Would you be willing to try the patch below in your environment? > > It addresses the stall I can create with a file that has a VERY large hole. > > In addition, it passes libhugetlbfs tests and has run for a while in my > > truncate/page fault race stress test. However, it is very early code. > > It would be nice to see if it addresses the issue in your environment. > > Yes, that fixes the issue for me. I added some debugging yesterday > evening after sending the initial report, and the end value in the loop > was indeed quite large - i didn't record the exact number, but it was > something like 0xffffffffff800001. Feel free to add my Tested-by. > Thank you! When thinking about this some more, the new vma_lock introduced by this series may address truncation/fault races without the need of involving the fault mutex. How? Before truncating or hole punching, we need to unmap all users of that range. To unmap, we need to acquire the vma_lock for each vma mapping the file. This same lock is acquired in the page fault path. As such, it provides the same type of synchronization around i_size as provided by the fault mutex in this patch. So, I think we can make the code much simpler (and faster) by removing the code taking the fault mutex for holes in files. Of course, this can not happen until the vma_lock is actually put into use which is done in the last patch of this series. -- Mike Kravetz
