diff options
author | Krutika Dhananjay <kdhananj@redhat.com> | 2019-01-24 14:14:39 +0530 |
---|---|---|
committer | Xavi Hernandez <xhernandez@redhat.com> | 2019-01-24 18:14:57 +0000 |
commit | 72922c1fd69191b220f79905a23395c3a87f86ce (patch) | |
tree | 853a020c4659013434ae667d59c00a96fca63f7a /COPYING-GPLV2 | |
parent | 99b3ab0cf3d3389a2ff89c29cfff906cd36693a3 (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