summaryrefslogtreecommitdiffstats
path: root/fs/gfs2/glock.c
diff options
context:
space:
mode:
authorSteven Whitehouse <swhiteho@redhat.com>2011-05-05 13:35:40 +0200
committerSteven Whitehouse <swhiteho@redhat.com>2011-05-05 13:35:40 +0200
commitd192a8e5c6fec4fe8cdafebccc415db4074dee88 (patch)
tree7c66540003f6aea894578f6786599bd08dcb9b7f /fs/gfs2/glock.c
parentGFS2: Improve bug trap code in ->releasepage() (diff)
downloadlinux-d192a8e5c6fec4fe8cdafebccc415db4074dee88.tar.xz
linux-d192a8e5c6fec4fe8cdafebccc415db4074dee88.zip
GFS2: Double check link count under glock
To avoid any possible races relating to the link count, we need to recheck it under the inode's glock in all cases where it matters. Also to ensure we never get any nasty surprises, this patch also ensures that once the link count has hit zero it can never be elevated by rereading in data from disk. The only place we cannot provide a proper solution is in rename in the case where we are removing a target inode and we discover that the target inode has been already unlinked on another node. The race window is very small, and we return EAGAIN in this case to indicate what has happened. The proper solution would be to move the lookup parts of rename from the vfs into library calls which the fs could call directly, but that is potentially a very big job and this fix should cover most cases for now. Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Diffstat (limited to 'fs/gfs2/glock.c')
0 files changed, 0 insertions, 0 deletions