On Mon 02-05-11 10:41:55, Christoph Hellwig wrote: > On Mon, May 02, 2011 at 04:20:55PM +0200, Jan Kara wrote: > > Hmm, but what prevents the following race? > > > > Thread 1 Thread 2 > > .. > > xfs_trans_alloc() > > xfs_wait_for_freeze(mp, SB_FREEZE_TRANS); > > freeze_super() > > sb->s_frozen = SB_FREEZE_TRANS; > > ... > > xfs_fs_freeze() > > ... > > xfs_quiesce_attr() > > waits for all active > transactions > > > ... > > xfs_trans_alloc > -> blocks in xfs_wait_for_freeze But why should it block when xfs_wait_for_freeze() gets called before freeze_super() gets called? The other thread calls freeze_super() just after xfs_wait_for_freeze() in thread 1 and before _xfs_trans_alloc() gets called. Or am I missing some serialization somewhere? > (thus doesn't get to _xfs_trans_alloc) > > > _xfs_trans_alloc() > > atomic_inc(&mp->m_active_trans); > > ... goes on modifying the filesystem > > > > It seems to be a similar problem as in ext4 - the atomic_inc() and > > vfs_check_frozen() are in the wrong order... > > I can't see the problem in this scheme. Note that we want > _xfs_trans_alloc to be able to create a transaction for > xfs_fs_log_dummy, so that we can write the dummy log record after > freezing out all other transactions, so that one is special cased > and doesn't do the xfs_wait_for_freeze. OK. Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- 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
