Filesystems appear to be using ->dirty_inode, expecting that the dirtying operating is done and visible to all CPUs (eg. setting private inode dirty bits, without any barriers themselves). So release the dirty "critical section" with a barrier before calling ->dirty_inode. Cost is not significantly changed, because we're just moving the barrier. Those filesystems that do use ->dirty_inode should have to care slightly less about barriers, which is a good thing. Signed-off-by: Nick Piggin <npiggin@xxxxxxxxx> Index: linux-2.6/fs/fs-writeback.c =================================================================== --- linux-2.6.orig/fs/fs-writeback.c 2010-11-19 16:47:00.000000000 +1100 +++ linux-2.6/fs/fs-writeback.c 2010-11-19 16:49:39.000000000 +1100 @@ -934,6 +934,15 @@ void __mark_inode_dirty(struct inode *in bool wakeup_bdi = false; /* + * Make sure that changes are seen by all cpus before we test i_state + * or mark anything as being dirty. Ie. all dirty state should be + * written to the inode and visible. Like an "unlock" operation, the + * mark_inode_dirty call must "release" our ordering window that is + * opened when we started modifying the inode. + */ + smp_mb(); + + /* * Don't do this for I_DIRTY_PAGES - that doesn't actually * dirty the inode itself */ @@ -942,12 +951,6 @@ void __mark_inode_dirty(struct inode *in sb->s_op->dirty_inode(inode); } - /* - * make sure that changes are seen by all cpus before we test i_state - * -- mikulas - */ - smp_mb(); - /* avoid the locking if we can */ if ((inode->i_state & flags) == flags) return; -- 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
