[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110502142055.GF4556@quack.suse.cz>
Date: Mon, 2 May 2011 16:20:55 +0200
From: Jan Kara <jack@...e.cz>
To: Christoph Hellwig <hch@...radead.org>
Cc: Jan Kara <jack@...e.cz>,
Surbhi Palande <surbhi.palande@...ntu.com>,
Dave Chinner <david@...morbit.com>,
Toshiyuki Okajima <toshi.okajima@...fujitsu.com>,
Ted Ts'o <tytso@....edu>,
Masayoshi MIZUMA <m.mizuma@...fujitsu.com>,
Andreas Dilger <adilger.kernel@...ger.ca>,
linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [RFC][PATCH] Re: [BUG] ext4: cannot unfreeze a filesystem due
to a deadlock
On Mon 02-05-11 09:22:04, Christoph Hellwig wrote:
> On Mon, May 02, 2011 at 03:16:19PM +0200, Jan Kara wrote:
> > Dave, Christoph, any opinions on this?
>
> The busyloop in xfs_quiesce_attr which waits for all active transactions
> to finish is supposed to fix this issue.
Hmm, but what prevents the following race?
Thread 1 Thread 2
..
xfs_trans_alloc()
xfs_wait_for_freeze(mp, SB_FREEZE_TRANS);
freeze_super()
...
xfs_fs_freeze()
...
xfs_quiesce_attr()
...
_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...
> Note that XFS traditionally expects a two stage freeze process where
> we first freeze new VFS-level writes, then flush the caches and then
> stop transactions, wait for them to finish and do the remainder of
> the freeze process, but I really messed that process up when moving
> the sequence to generic code. Funnily enough it seems to work
> neverless.
Honza
--
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists