linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Stefan Bader <stefan.bader@canonical.com>
Cc: Greg KH <gregkh@suse.de>,
	linux-kernel@vger.kernel.org, stable@kernel.org,
	akpm@linux-foundation.org, torvalds@linux-foundation.org,
	stable-review@kernel.org, alan@lxorguk.ukuu.org.uk
Subject: Re: [Stable-review] [116/165] ext4: dont return to userspace after freezing the fs with a mutex held
Date: Mon, 02 Aug 2010 12:02:45 -0500	[thread overview]
Message-ID: <4C56FA35.7060607@redhat.com> (raw)
In-Reply-To: <4C56B45E.9010601@canonical.com>

On 08/02/2010 07:04 AM, Stefan Bader wrote:
> We have reports about this patch breaking lvm snapshhots. Eric, there is a patch
> mentioned which is supposed to fix things but its not upstream, yet.
> Do you know what happened to that?

right, patch below is needed to fix things.

Ted just acked it on the list recently; Greg, I'd either drop 116/165
for now, or include the patch below which should be upstream soon...

-Eric

> -Stefan
> 
> PATCH] ext4: fix freeze deadlock under IO
> 
> Commit 6b0310fbf087ad6 caused a regression resulting in deadlocks
> when freezing a filesystem which had active IO; the vfs_check_frozen
> level (SB_FREEZE_WRITE) did not let the freeze-related IO syncing
> through.  Duh.
> 
> Changing the test to FREEZE_TRANS should let the normal freeze
> syncing get through the fs, but still block any transactions from
> starting once the fs is completely frozen.
> 
> I tested this by running fsstress in the background while periodically
> snapshotting the fs and running fsck on the result.  I ran into
> occasional deadlocks, but different ones.  I think this is a
> fine fix for the problem at hand, and the other deadlocky things
> will need more investigation.
> 
> Reported-by: Phillip Susi <psusi@cfl.rr.com>
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> ---
> 
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index 4e8983a..a45ced9 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -241,7 +241,7 @@ handle_t *ext4_journal_start_sb(struct super_block *sb, int
> nblocks)
>  	if (sb->s_flags & MS_RDONLY)
>  		return ERR_PTR(-EROFS);
> 
> -	vfs_check_frozen(sb, SB_FREEZE_WRITE);
> +	vfs_check_frozen(sb, SB_FREEZE_TRANS);
>  	/* Special case here: if the journal has aborted behind our
>  	 * backs (eg. EIO in the commit thread), then we still need to
>  	 * take the FS itself readonly cleanly. */
> @@ -3491,7 +3491,7 @@ int ext4_force_commit(struct super_block *sb)
> 
>  	journal = EXT4_SB(sb)->s_journal;
>  	if (journal) {
> -		vfs_check_frozen(sb, SB_FREEZE_WRITE);
> +		vfs_check_frozen(sb, SB_FREEZE_TRANS);
>  		ret = ext4_journal_force_commit(journal);
>  	}
> 
> 
> 
> On 07/30/2010 07:15 PM, Greg KH wrote:
>> 2.6.32-stable review patch.  If anyone has any objections, please let us know.
>>
>> ------------------
>>
>> commit 6b0310fbf087ad6e9e3b8392adca97cd77184084 upstream (as of v2.6.34-git13)
>>
>> ext4_freeze() used jbd2_journal_lock_updates() which takes
>> the j_barrier mutex, and then returns to userspace.  The
>> kernel does not like this:
>>
>> ================================================
>> [ BUG: lock held when returning to user space! ]
>> ------------------------------------------------
>> lvcreate/1075 is leaving the kernel with locks still held!
>> 1 lock held by lvcreate/1075:
>>  #0:  (&journal->j_barrier){+.+...}, at: [<ffffffff811c6214>]
>> jbd2_journal_lock_updates+0xe1/0xf0
>>
>> Use vfs_check_frozen() added to ext4_journal_start_sb() and
>> ext4_force_commit() instead.
>>
>> Addresses-Red-Hat-Bugzilla: #568503
>>
>> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
>> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
>> ---
>>  fs/ext4/super.c |   20 ++++++++++----------
>>  1 file changed, 10 insertions(+), 10 deletions(-)
>>
>> --- a/fs/ext4/super.c
>> +++ b/fs/ext4/super.c
>> @@ -227,6 +227,7 @@ handle_t *ext4_journal_start_sb(struct s
>>  	if (sb->s_flags & MS_RDONLY)
>>  		return ERR_PTR(-EROFS);
>>  
>> +	vfs_check_frozen(sb, SB_FREEZE_WRITE);
>>  	/* Special case here: if the journal has aborted behind our
>>  	 * backs (eg. EIO in the commit thread), then we still need to
>>  	 * take the FS itself readonly cleanly. */
>> @@ -3391,8 +3392,10 @@ int ext4_force_commit(struct super_block
>>  		return 0;
>>  
>>  	journal = EXT4_SB(sb)->s_journal;
>> -	if (journal)
>> +	if (journal) {
>> +		vfs_check_frozen(sb, SB_FREEZE_WRITE);
>>  		ret = ext4_journal_force_commit(journal);
>> +	}
>>  
>>  	return ret;
>>  }
>> @@ -3441,18 +3444,16 @@ static int ext4_freeze(struct super_bloc
>>  	 * the journal.
>>  	 */
>>  	error = jbd2_journal_flush(journal);
>> -	if (error < 0) {
>> -	out:
>> -		jbd2_journal_unlock_updates(journal);
>> -		return error;
>> -	}
>> +	if (error < 0)
>> +		goto out;
>>  
>>  	/* Journal blocked and flushed, clear needs_recovery flag. */
>>  	EXT4_CLEAR_INCOMPAT_FEATURE(sb, EXT4_FEATURE_INCOMPAT_RECOVER);
>>  	error = ext4_commit_super(sb, 1);
>> -	if (error)
>> -		goto out;
>> -	return 0;
>> +out:
>> +	/* we rely on s_frozen to stop further updates */
>> +	jbd2_journal_unlock_updates(EXT4_SB(sb)->s_journal);
>> +	return error;
>>  }
>>  
>>  /*
>> @@ -3469,7 +3470,6 @@ static int ext4_unfreeze(struct super_bl
>>  	EXT4_SET_INCOMPAT_FEATURE(sb, EXT4_FEATURE_INCOMPAT_RECOVER);
>>  	ext4_commit_super(sb, 1);
>>  	unlock_super(sb);
>> -	jbd2_journal_unlock_updates(EXT4_SB(sb)->s_journal);
>>  	return 0;
>>  }
>>  
>>
>>
>> _______________________________________________
>> Stable-review mailing list
>> Stable-review@linux.kernel.org
>> http://linux.kernel.org/mailman/listinfo/stable-review
> 


  reply	other threads:[~2010-08-02 17:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-30 17:15 [116/165] ext4: dont return to userspace after freezing the fs with a mutex held Greg KH
2010-08-02 12:04 ` [Stable-review] " Stefan Bader
2010-08-02 17:02   ` Eric Sandeen [this message]
2010-08-02 18:48     ` [stable] " Greg KH
2010-08-07  4:07       ` Henrique de Moraes Holschuh
2010-08-07  5:15         ` Greg KH
2010-08-07 13:38         ` Eric Sandeen
2010-08-09  9:00           ` Stefan Bader
2010-08-10 20:16             ` Greg KH
2010-08-11  8:56               ` Stefan Bader
2010-08-11 12:20                 ` Eric Sandeen
2010-08-11 12:34                   ` [Stable-review] [stable] " Ted Ts'o
2018-07-05 16:25             ` [stable] [Stable-review] " Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C56FA35.7060607@redhat.com \
    --to=sandeen@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable-review@kernel.org \
    --cc=stable@kernel.org \
    --cc=stefan.bader@canonical.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).