summaryrefslogtreecommitdiff
path: root/.gitattributes
diff options
context:
space:
mode:
authorJianyong Wu <jianyong.wu@arm.com>2020-09-23 22:11:46 +0800
committerDominique Martinet <asmadeus@codewreck.org>2020-11-19 17:20:39 +0100
commit6636b6dcc3db2258cd0585b8078c1c225c4b6dde (patch)
tree00d30096cadaafcee0cd79206fa0f6da315aa445 /.gitattributes
parent478ba09edc1f2f2ee27180a06150cb2d1a686f9c (diff)
9p: add refcount to p9_fid struct
Fix race issue in fid contention. Eric's and Greg's patch offer a mechanism to fix open-unlink-f*syscall bug in 9p. But there is race issue in fid parallel accesses. As Greg's patch stores all of fids from opened files into according inode, so all the lookup fid ops can retrieve fid from inode preferentially. But there is no mechanism to handle the fid contention issue. For example, there are two threads get the same fid in the same time and one of them clunk the fid before the other thread ready to discard the fid. In this scenario, it will lead to some fatal problems, even kernel core dump. I introduce a mechanism to fix this race issue. A counter field introduced into p9_fid struct to store the reference counter to the fid. When a fid is allocated from the inode or dentry, the counter will increase, and will decrease at the end of its occupation. It is guaranteed that the fid won't be clunked before the reference counter go down to 0, then we can avoid the clunked fid to be used. tests: race issue test from the old test case: for file in {01..50}; do touch f.${file}; done seq 1 1000 | xargs -n 1 -P 50 -I{} cat f.* > /dev/null open-unlink-f*syscall test: I have tested for f*syscall include: ftruncate fstat fchown fchmod faccessat. Link: http://lkml.kernel.org/r/20200923141146.90046-5-jianyong.wu@arm.com Fixes: 478ba09edc1f ("fs/9p: search open fids first") Signed-off-by: Jianyong Wu <jianyong.wu@arm.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
Diffstat (limited to '.gitattributes')
0 files changed, 0 insertions, 0 deletions