[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1252410063-26872-1-git-send-email-jack@suse.cz>
Date: Tue, 8 Sep 2009 13:41:03 +0200
From: Jan Kara <jack@...e.cz>
To: LKML <linux-kernel@...r.kernel.org>
Cc: linux-fsdevel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>, hch@...radead.org,
Jan Kara <jack@...e.cz>
Subject: [PATCH] fs: Make sure data stored into inode is properly seen before unlocking new inode
In theory it could happen that on one CPU we initialize a new inode but clearing
of I_NEW | I_LOCK gets reordered before some of the initialization. Thus on
another CPU we return not fully uptodate inode from iget_locked().
This seems to fix a corruption issue on ext3 mounted over NFS.
Signed-off-by: Jan Kara <jack@...e.cz>
---
fs/inode.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Since Al doesn't seem to be online, does anybody else have opinion on this
patch? I can merge it via my tree but I'd like to get a review from someone
else.
diff --git a/fs/inode.c b/fs/inode.c
index 901bad1..e9a8e77 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -696,6 +696,7 @@ void unlock_new_inode(struct inode *inode)
* just created it (so there can be no old holders
* that haven't tested I_LOCK).
*/
+ smp_mb();
WARN_ON((inode->i_state & (I_LOCK|I_NEW)) != (I_LOCK|I_NEW));
inode->i_state &= ~(I_LOCK|I_NEW);
wake_up_inode(inode);
--
1.6.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists