Fix i_state of the inode is changed after the inode is freed.
Signed-off-by: Masayuki Saito <[email protected]>
Signed-off-by: ASANO Masahiro <[email protected]>
---
--- linux-2.6.17.7/fs/xfs/xfs_inode.c.orig 2006-08-21 20:15:58.385211286 +0900
+++ linux-2.6.17.7/fs/xfs/xfs_inode.c 2006-08-21 21:21:22.277033371 +0900
@@ -2751,18 +2751,30 @@ xfs_iunpin(
* call as the inode reclaim may be blocked waiting for
* the inode to become unpinned.
*/
+ int need_iput = 0;
+ struct inode *inode;
+ spin_lock(&ip->i_flags_lock);
if (!(ip->i_flags & (XFS_IRECLAIM|XFS_IRECLAIMABLE))) {
vnode_t *vp = XFS_ITOV_NULL(ip);
/* make sync come back and flush this inode */
if (vp) {
- struct inode *inode = vn_to_inode(vp);
+ inode = vn_to_inode(vp);
- if (!(inode->i_state & I_NEW))
- mark_inode_dirty_sync(inode);
+ if (!(inode->i_state &
+ (I_NEW|I_FREEING|I_CLEAR))) {
+ inode = igrab(inode);
+ if (inode) {
+ need_iput = 1;
+ mark_inode_dirty_sync(inode);
+ }
+ }
}
}
+ spin_unlock(&ip->i_flags_lock);
wake_up(&ip->i_ipin_wait);
+ if (need_iput)
+ iput(inode);
}
}
On Wed, Aug 23, 2006 at 08:14:45PM +0900, Masayuki Saito wrote:
> Fix i_state of the inode is changed after the inode is freed.
>
> Signed-off-by: Masayuki Saito <[email protected]>
> Signed-off-by: ASANO Masahiro <[email protected]>
This version is producing a gcc warning...
fs/xfs/xfs_inode.c: In function 'xfs_iunpin':
fs/xfs/xfs_inode.c:2765: warning: 'inode' may be used uninitialized in this function
Which doesn't look correct due to your need_iput guard, but perhaps
we should do this instead...
cheers.
--
Nathan
Fix i_state of the inode is changed after the inode is freed.
Signed-off-by: Masayuki Saito <[email protected]>
Signed-off-by: ASANO Masahiro <[email protected]>
---
Index: xfs-linux/xfs_inode.c
===================================================================
--- xfs-linux.orig/xfs_inode.c 2006-08-24 17:02:36.896740000 +1000
+++ xfs-linux/xfs_inode.c 2006-08-24 17:09:29.430521750 +1000
@@ -2761,19 +2761,29 @@ xfs_iunpin(
* call as the inode reclaim may be blocked waiting for
* the inode to become unpinned.
*/
+ struct inode *inode = NULL;
+
+ spin_lock(&ip->i_flags_lock);
if (!(ip->i_flags & (XFS_IRECLAIM|XFS_IRECLAIMABLE))) {
bhv_vnode_t *vp = XFS_ITOV_NULL(ip);
/* make sync come back and flush this inode */
if (vp) {
- struct inode *inode = vn_to_inode(vp);
+ inode = vn_to_inode(vp);
if (!(inode->i_state &
- (I_NEW|I_FREEING|I_CLEAR)))
- mark_inode_dirty_sync(inode);
+ (I_NEW|I_FREEING|I_CLEAR))) {
+ inode = igrab(inode);
+ if (inode)
+ mark_inode_dirty_sync(inode);
+ } else
+ inode = NULL;
}
}
+ spin_unlock(&ip->i_flags_lock);
wake_up(&ip->i_ipin_wait);
+ if (inode)
+ iput(inode);
}
}
Hi, Nathan
>Which doesn't look correct due to your need_iput guard, but perhaps
>we should do this instead...
I think that your fix is simpler, so I agree it.
Masayuki
Hi, Nathan
>Fix i_state of the inode is changed after the inode is freed.
>
>Signed-off-by: Masayuki Saito <[email protected]>
>Signed-off-by: ASANO Masahiro <[email protected]>
>---
>
>Index: xfs-linux/xfs_inode.c
>===================================================================
>--- xfs-linux.orig/xfs_inode.c 2006-08-24 17:02:36.896740000 +1000
>+++ xfs-linux/xfs_inode.c 2006-08-24 17:09:29.430521750 +1000
>@@ -2761,19 +2761,29 @@ xfs_iunpin(
> * call as the inode reclaim may be blocked waiting for
> * the inode to become unpinned.
> */
>+ struct inode *inode = NULL;
>+
>+ spin_lock(&ip->i_flags_lock);
> if (!(ip->i_flags & (XFS_IRECLAIM|XFS_IRECLAIMABLE))) {
> bhv_vnode_t *vp = XFS_ITOV_NULL(ip);
>
> /* make sync come back and flush this inode */
> if (vp) {
>- struct inode *inode = vn_to_inode(vp);
>+ inode = vn_to_inode(vp);
>
> if (!(inode->i_state &
>- (I_NEW|I_FREEING|I_CLEAR)))
>- mark_inode_dirty_sync(inode);
>+ (I_NEW|I_FREEING|I_CLEAR))) {
>+ inode = igrab(inode);
>+ if (inode)
>+ mark_inode_dirty_sync(inode);
>+ } else
>+ inode = NULL;
> }
> }
>+ spin_unlock(&ip->i_flags_lock);
> wake_up(&ip->i_ipin_wait);
>+ if (inode)
>+ iput(inode);
> }
> }
Are the patches going to be merged?
Masayuki
On Thu, Aug 31, 2006 at 11:44:23AM +0900, Masayuki Saito wrote:
> Hi, Nathan
>
> Are the patches going to be merged?
Yep, they're queued up for 2.6.19. Since it was a race found
only on testing with a ramdisk (iirc) it didn't really seem to
me like they needed to be rushed through for a 2.6.18-rc. The
race has also been there for the entire lifetime of the Linux
XFS port... so, not urgent (and not risk free either).
cheers.
--
Nathan
>> Are the patches going to be merged?
>
>Yep, they're queued up for 2.6.19. Since it was a race found
>only on testing with a ramdisk (iirc) it didn't really seem to
>me like they needed to be rushed through for a 2.6.18-rc. The
>race has also been there for the entire lifetime of the Linux
>XFS port... so, not urgent (and not risk free either).
Thanks, I agree it. I'm looking forward to receiving the TAKE.
So far thank you, Nathan. I wish to be glorious in your future.
cheers.
--
Masayuki