From 1ae7000630e3c05b6f7e3dfc76472f1bca6c1788 Mon Sep 17 00:00:00 2001 From: Hugh Dickins Date: Thu, 29 Mar 2007 01:20:36 -0700 Subject: [PATCH] [PATCH] holepunch: fix shmem_truncate_range punch locking 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: Hugh Dickins Cc: Miklos Szeredi Cc: Badari Pulavarty Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Reading git-format-patch failed