• Hugh Dickins's avatar
    [PATCH] holepunch: fix shmem_truncate_range punch locking · 1ae70006
    Hugh Dickins authored
    Miklos Szeredi observes that during truncation of shmem page directories,
    info->lock is released to improve latency (after lowering i_size and
    next_index to exclude races); but this is quite wrong for holepunching, which
    receives no such protection from i_size or next_index, and is left vulnerable
    to races with shmem_unuse, shmem_getpage and shmem_writepage.
    
    Hold info->lock throughout when holepunching?  No, any user could prevent
    rescheduling for far too long.  Instead take info->lock just when needed: in
    shmem_free_swp when removing the swap entries, and whenever removing a
    directory page from the level above.  But so long as we remove before
    scanning, we can safely skip taking the lock at the lower levels, except at
    misaligned start and end of the hole.
    Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
    Cc: Miklos Szeredi <mszeredi@suse.cz>
    Cc: Badari Pulavarty <pbadari@us.ibm.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    1ae70006
shmem.c 65.1 KB