summaryrefslogtreecommitdiffstats
path: root/firmware/3com
diff options
context:
space:
mode:
authorwengang wang <wen.gang.wang@oracle.com>2009-03-06 21:29:10 +0800
committerMark Fasheh <mfasheh@suse.com>2009-04-03 11:39:25 -0700
commit6ca497a83e592d64e050c4d04b6dedb8c915f39a (patch)
tree0b9cd611d6d907881841eca73d12a7f3b85f1716 /firmware/3com
parent9405dccfd3201d2b76e120949bec81ba8cfbd2d0 (diff)
downloadlinux-6ca497a83e592d64e050c4d04b6dedb8c915f39a.tar.bz2
ocfs2: fix rare stale inode errors when exporting via nfs
For nfs exporting, ocfs2_get_dentry() returns the dentry for fh. ocfs2_get_dentry() may read from disk when the inode is not in memory, without any cross cluster lock. this leads to the file system loading a stale inode. This patch fixes above problem. Solution is that in case of inode is not in memory, we get the cluster lock(PR) of alloc inode where the inode in question is allocated from (this causes node on which deletion is done sync the alloc inode) before reading out the inode itsself. then we check the bitmap in the group (the inode in question allcated from) to see if the bit is clear. if it's clear then it's stale. if the bit is set, we then check generation as the existing code does. We have to read out the inode in question from disk first to know its alloc slot and allot bit. And if its not stale we read it out using ocfs2_iget(). The second read should then be from cache. And also we have to add a per superblock nfs_sync_lock to cover the lock for alloc inode and that for inode in question. this is because ocfs2_get_dentry() and ocfs2_delete_inode() lock on them in reverse order. nfs_sync_lock is locked in EX mode in ocfs2_get_dentry() and in PR mode in ocfs2_delete_inode(). so that mutliple ocfs2_delete_inode() can run concurrently in normal case. [mfasheh@suse.com: build warning fixes and comment cleanups] Signed-off-by: Wengang Wang <wen.gang.wang@oracle.com> Acked-by: Joel Becker <joel.becker@oracle.com> Signed-off-by: Mark Fasheh <mfasheh@suse.com>
Diffstat (limited to 'firmware/3com')
0 files changed, 0 insertions, 0 deletions