----- Original Message ----- | This patch set my Bob and me avoids a deadlock in gfs2 when an inode is being | freed: normally, when find_inode finds an inode in I_FREEING or I_WILL_FREE | state, it waits for the inode to go away before returning | (__wait_on_freeing_inode). Freeing an inode on gfs2 requires taking the | inode's glock. However, in gfs2_lookup_by_inum, we need to be holding the | inode glock while doing lookups, so we can deadlock with processes | concurrently | freeing inodes. | | This patch set allows gfs2_lookup_by_inum to drop the inode glock before | waiting for inodes to go away. We could try non-blocking lookups and wait | for | an arbitrary amount of time before retrying the lookup instead as well, but | waiting for the actual event (i.e., the inode being freed to likely have | disappeared) makes more sense. | | Thanks, | Andreas | | Andreas Gruenbacher (5): | GFS2: Remove superfluous assignment | GFS2: No need for non-blocking gfs2_ilookup in delete_work_func | vfs: Introduce prepare_wait_on_freeing_inode | GFS2: Use non-blocking wait in gfs2_iget | GFS2: Prevent deadlock in gfs2_lookup_by_inum | | Bob Peterson (2): | Revert "GFS2: Eliminate parameter non_block on gfs2_inode_lookup" | Revert "GFS2: Don't filter out I_FREEING inodes anymore" | | fs/gfs2/dir.c | 2 +- | fs/gfs2/glock.c | 4 +- | fs/gfs2/inode.c | 109 | ++++++++++++++++++++++++++++++++++++++++++++++----- | fs/gfs2/inode.h | 8 +++- | fs/gfs2/ops_fstype.c | 2 +- | fs/inode.c | 18 +++++++-- | include/linux/fs.h | 1 + | include/linux/wait.h | 21 +++++++--- | 8 files changed, 142 insertions(+), 23 deletions(-) | | -- | 2.5.5 Hi Miklos and Al, Did you two guys see the vfs-related changes contained in the patch set sent by Andreas on 13 May, and resent by me on 24 May? We have not received any comments about the patches, but since they affect VFS, I wanted to be sure you two looked them over before I pushed them to the gfs2 for-next tree. I just don't want to be accused of trying to slip this in under the radar or you guys being taken by surprise. Regards, Bob Peterson Red Hat File Systems -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
