Re: [PATCH] Btrfs: fix heavy delalloc related deadlock

[Josef Bacik <jbacik@fusionio.com>]

On Mon, Aug 19, 2013 at 10:31:15AM +0800, Miao Xie wrote:
> On wed, 14 Aug 2013 11:41:00 -0400, Josef Bacik wrote:
> > I added a patch where we started taking the ordered operations mutex when we
> > waited on ordered extents.  We need this because we splice the list and process
> > it, so if a flusher came in during this scenario it would think the list was
> > empty and we'd usually get an early ENOSPC.  The problem with this is that this
> > lock is used in transaction committing.  So we end up with something like this
> > 
> > Transaction commit
> > 	-> wait on writers
> > 
> > Delalloc flusher
> > 	-> run_ordered_operations (holds mutex)
> > 		->wait for filemap-flush to do its thing
> > 
> > flush task
> > 	-> cow_file_range
> > 		->wait on btrfs_join_transaction because we're commiting
> > 
> > some other task
> > 	-> commit_transaction because we notice trans->transaction->flush is set
> > 		-> run_ordered_operations (hang on mutex)
> 
> Sorry, I can not understand this explanation. As far as I know, if the flush task
> waits on btrfs_join_transaction(), it means the transaction is under commit
> (state = TRANS_STATE_COMMIT_DOING), and all the external writers(TRANS_START/TRANS_ATTACH/
> TRANS_USERSPACE) have quitted the current transaction, so no one would try to call
> run_ordered_operations().
> 
> Could you show us the reproduce steps?
> 

Sorry I wrote the wrong thing for the delalloc flusher, that should be

  ->btrfs_wait_ordered_extents (holds ordered operations mutex)
	-> wait for filemap-flush to do its thing

That should make it clearer.  I reproduced it running xfstests generic/224.
Thanks,

Josef