summaryrefslogtreecommitdiff
path: root/crypto/salsa20_generic.c
diff options
context:
space:
mode:
authorYan, Zheng <zheng.z.yan@intel.com>2013-08-13 04:42:15 (GMT)
committerSage Weil <sage@inktank.com>2013-08-15 18:12:06 (GMT)
commitb0d7c2231015b331b942746610a05b6ea72977ab (patch)
treea13e3f015fc3144371550b4f5c25363bd66bdf1f /crypto/salsa20_generic.c
parentb150f5c1c759d551da9146435d3dc9df5f7e15ef (diff)
downloadlinux-fsl-qoriq-b0d7c2231015b331b942746610a05b6ea72977ab.tar.xz
ceph: introduce i_truncate_mutex
I encountered below deadlock when running fsstress wmtruncate work truncate MDS --------------- ------------------ -------------------------- lock i_mutex <- truncate file lock i_mutex (blocked) <- revoking Fcb (filelock to MIX) send request -> handle request (xlock filelock) At the initial time, there are some dirty pages in the page cache. When the kclient receives the truncate message, it reduces inode size and creates some 'out of i_size' dirty pages. wmtruncate work can't truncate these dirty pages because it's blocked by the i_mutex. Later when the kclient receives the cap message that revokes Fcb caps, It can't flush all dirty pages because writepages() only flushes dirty pages within the inode size. When the MDS handles the 'truncate' request from kclient, it waits for the filelock to become stable. But the filelock is stuck in unstable state because it can't finish revoking kclient's Fcb caps. The truncate pagecache locking has already caused lots of trouble for use. I think it's time simplify it by introducing a new mutex. We use the new mutex to prevent concurrent truncate_inode_pages(). There is no need to worry about race between buffered write and truncate_inode_pages(), because our "get caps" mechanism prevents them from concurrent execution. Reviewed-by: Sage Weil <sage@inktank.com> Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
Diffstat (limited to 'crypto/salsa20_generic.c')
0 files changed, 0 insertions, 0 deletions