summaryrefslogtreecommitdiffstats
path: root/COPYING-GPLV2
diff options
context:
space:
mode:
authorKrutika Dhananjay <kdhananj@redhat.com>2019-01-24 14:14:39 +0530
committerXavi Hernandez <xhernandez@redhat.com>2019-01-24 18:14:57 +0000
commit72922c1fd69191b220f79905a23395c3a87f86ce (patch)
tree853a020c4659013434ae667d59c00a96fca63f7a /COPYING-GPLV2
parent99b3ab0cf3d3389a2ff89c29cfff906cd36693a3 (diff)
features/shard: Ref shard inode while adding to fsync list
PROBLEM: Lot of the earlier changes in the management of shards in lru, fsync lists assumed that if a given shard exists in fsync list, it must be part of lru list as well. This was found to be not true. Consider this - a file is FALLOCATE'd to a size which would make the number of participant shards to be greater than the lru list size. In this case, some of the resolved shards that are to participate in this fop will be evicted from lru list to give way to the rest of the shards. And once FALLOCATE completes, these shards are added to fsync list but without a ref. After the fop completes, these shard inodes are unref'd and destroyed while their inode ctxs are still part of fsync list. Now when an FSYNC is called on the base file and the fsync-list traversed, the client crashes due to illegal memory access. FIX: Hold a ref on the shard inode when adding to fsync list as well. And unref under following conditions: 1. when the shard is evicted from lru list 2. when the base file is fsync'd 3. when the shards are deleted. Change-Id: Iab460667d091b8388322f59b6cb27ce69299b1b2 fixes: bz#1669077 Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com>
Diffstat (limited to 'COPYING-GPLV2')
0 files changed, 0 insertions, 0 deletions