On 06/15/2014 10:29 PM, Hugh Dickins wrote: > On Thu, 12 Jun 2014, Sasha Levin wrote: >> > On 02/09/2014 08:41 PM, Sasha Levin wrote: >>> > > On 02/08/2014 10:25 PM, Hugh Dickins wrote: >>>> > >> Would trinity be likely to have a thread or process repeatedly faulting >>>> > >> in pages from the hole while it is being punched? >>> > > >>> > > I can see how trinity would do that, but just to be certain - Cc davej. >>> > > >>> > > On 02/08/2014 10:25 PM, Hugh Dickins wrote: >>>> > >> Does this happen with other holepunch filesystems? If it does not, >>>> > >> I'd suppose it's because the tmpfs fault-in-newly-created-page path >>>> > >> is lighter than a consistent disk-based filesystem's has to be. >>>> > >> But we don't want to make the tmpfs path heavier to match them. >>> > > >>> > > No, this is strictly limited to tmpfs, and AFAIK trinity tests hole >>> > > punching in other filesystems and I make sure to get a bunch of those >>> > > mounted before starting testing. >> > >> > Just pinging this one again. I still see hangs in -next where the hang >> > location looks same as before: >> > > Please give this patch a try. It fixes what I can reproduce, but given > your unexplained page_mapped() BUG in this area, we know there's more > yet to be understood, so perhaps this patch won't do enough for you. > > > [PATCH] shmem: fix faulting into a hole while it's punched > > Trinity finds that mmap access to a hole while it's punched from shmem > can prevent the madvise(MADV_REMOVE) or fallocate(FALLOC_FL_PUNCH_HOLE) > from completing, until the reader chooses to stop; with the puncher's > hold on i_mutex locking out all other writers until it can complete. > > It appears that the tmpfs fault path is too light in comparison with > its hole-punching path, lacking an i_data_sem to obstruct it; but we > don't want to slow down the common case. > > Extend shmem_fallocate()'s existing range notification mechanism, so > shmem_fault() can refrain from faulting pages into the hole while it's > punched, waiting instead on i_mutex (when safe to sleep; or repeatedly > faulting when not). > > Signed-off-by: Hugh Dickins <hughd@xxxxxxxxxx> No shmem_fallocate issues observed in the past day, works for me. Thanks Hugh! Thanks, Sasha -- 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
