summaryrefslogtreecommitdiffstats
path: root/tools
diff options
context:
space:
mode:
authorSteven Whitehouse <swhiteho@redhat.com>2011-05-05 12:35:40 +0100
committerSteven Whitehouse <swhiteho@redhat.com>2011-05-05 12:35:40 +0100
commitd192a8e5c6fec4fe8cdafebccc415db4074dee88 (patch)
tree7c66540003f6aea894578f6786599bd08dcb9b7f /tools
parent8f065d36508f283ee6cbeb05829f032d0b782a16 (diff)
downloadlinux-d192a8e5c6fec4fe8cdafebccc415db4074dee88.tar.gz
linux-d192a8e5c6fec4fe8cdafebccc415db4074dee88.tar.bz2
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 'tools')
0 files changed, 0 insertions, 0 deletions