The locking in xfs_iget_cache_hit currently has numerous problems: - we clear the reclaim tag without i_flags_lock which protects modifications to it - we call inode_init_always which can sleep with
Any chance this could be broken into 2 patches starting with the set/clear cleanup something like: diff --git a/fs/xfs/linux-2.6/xfs_sync.c b/fs/xfs/linux-2.6/xfs_sync.c index b619d6b..49c7b6f 100644
Let's just drop those for now given that we're late enough in the cycle. New version below: -- The locking in xfs_iget_cache_hit currently has numerous problems: - we clear the reclaim tag without i_
The locking in xfs_iget_cache_hit currently has numerous problems: - we clear the reclaim tag without i_flags_lock which protects modifications to it - we call inode_init_always which can sleep with
The wait_on_inode is only sensible for the non-recycle case. But it's not actually very useful with our flags scheme, so for now I've reverted to do the old-style polling and just added an XXX commen
This seems ok to me but I have to be honest, I'm having a hard time getting my head around back into the inode lifecycle. one comment, I wonder if it's worth capturing the actual error from inode_ini
Another case when we find XFS_INEW set is the race with the cache miss, which just set up a new inode. Would the proposed code be still sensible in that case? If yes, at least comments should be upda
Yeah. The new version should fix it. Here's a version with the small update that Eric suggested, any chance we could get this into 2.6.31 still? -- The locking in xfs_iget_cache_hit currently has num
The case, I was referring to, was indeed the reclaimable one when the first thread is going through xfs_iget xfs_iget_cache_hit if (ip->i_flags & XFS_IRECLAIMABLE) { ip->i_flags |= XFS_INEW; xfs_setu