[116/165] ext4: dont return to userspace after freezing the fs with a mutex held

[116/165] ext4: dont return to userspace after freezing the fs with a mutex held

[Greg KH]

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;
 }
 

Re: [Stable-review] [116/165] ext4: dont return to userspace after freezing the fs with a mutex held

[Stefan Bader]

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?

-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

Re: [Stable-review] [116/165] ext4: dont return to userspace after freezing the fs with a mutex held

[Eric Sandeen]

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
> 

Re: [stable] [Stable-review] [116/165] ext4: dont return to userspace after freezing the fs with a mutex held

[Greg KH]

On Mon, Aug 02, 2010 at 12:02:45PM -0500, Eric Sandeen wrote:
> 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...

I can't take anything that isn't upstream yet.

And I just released with this patch in the kernel, should I do a revert
and do a new release?

thanks,

greg k-h

Re: [stable] [Stable-review] [116/165] ext4: dont return to userspace after freezing the fs with a mutex held

[Henrique de Moraes Holschuh]

On Mon, 02 Aug 2010, Greg KH wrote:
> On Mon, Aug 02, 2010 at 12:02:45PM -0500, Eric Sandeen wrote:
> > 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...
> 
> I can't take anything that isn't upstream yet.
> 
> And I just released with this patch in the kernel, should I do a revert
> and do a new release?

Any answers on this?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [stable] [Stable-review] [116/165] ext4: dont return to userspace after freezing the fs with a mutex held

[Greg KH]

On Sat, Aug 07, 2010 at 01:07:32AM -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 02 Aug 2010, Greg KH wrote:
> > On Mon, Aug 02, 2010 at 12:02:45PM -0500, Eric Sandeen wrote:
> > > 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...
> > 
> > I can't take anything that isn't upstream yet.
> > 
> > And I just released with this patch in the kernel, should I do a revert
> > and do a new release?
> 
> Any answers on this?

Nope :(

Re: [stable] [Stable-review] [116/165] ext4: dont return to userspace after freezing the fs with a mutex held

[Eric Sandeen]

Henrique de Moraes Holschuh wrote:
> On Mon, 02 Aug 2010, Greg KH wrote:
>> On Mon, Aug 02, 2010 at 12:02:45PM -0500, Eric Sandeen wrote:
>>> 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...
>> I can't take anything that isn't upstream yet.
>>
>> And I just released with this patch in the kernel, should I do a revert
>> and do a new release?
> 
> Any answers on this?
> 

Yes, I'd revert it for now, I'm afraid, if the other patch isn't upstream
yet.

Sorry about that,

-Eric

Re: [stable] [Stable-review] [116/165] ext4: dont return to userspace after freezing the fs with a mutex held

[Stefan Bader]

On 08/07/2010 03:38 PM, Eric Sandeen wrote:
> Henrique de Moraes Holschuh wrote:
>> On Mon, 02 Aug 2010, Greg KH wrote:
>>> On Mon, Aug 02, 2010 at 12:02:45PM -0500, Eric Sandeen wrote:
>>>> 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...
>>> I can't take anything that isn't upstream yet.
>>>
>>> And I just released with this patch in the kernel, should I do a revert
>>> and do a new release?
>>
>> Any answers on this?
>>
> 
> Yes, I'd revert it for now, I'm afraid, if the other patch isn't upstream
> yet.
> 
> Sorry about that,
> 
> -Eric

Upstream as of now (same SHA1 as in linux-next):

>From 437f88cc031ffe7f37f3e705367f4fe1f4be8b0f Mon Sep 17 00:00:00 2001
From: Eric Sandeen <sandeen@sandeen.net>
Date: Sun, 1 Aug 2010 17:33:29 -0400
Subject: [PATCH] (pre-stable) ext4: fix freeze deadlock under IO

-Stefan

Re: [stable] [Stable-review] [116/165] ext4: dont return to userspace after freezing the fs with a mutex held

[Greg KH]

On Mon, Aug 09, 2010 at 11:00:43AM +0200, Stefan Bader wrote:
> On 08/07/2010 03:38 PM, Eric Sandeen wrote:
> > Henrique de Moraes Holschuh wrote:
> >> On Mon, 02 Aug 2010, Greg KH wrote:
> >>> On Mon, Aug 02, 2010 at 12:02:45PM -0500, Eric Sandeen wrote:
> >>>> 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...
> >>> I can't take anything that isn't upstream yet.
> >>>
> >>> And I just released with this patch in the kernel, should I do a revert
> >>> and do a new release?
> >>
> >> Any answers on this?
> >>
> > 
> > Yes, I'd revert it for now, I'm afraid, if the other patch isn't upstream
> > yet.
> > 
> > Sorry about that,
> > 
> > -Eric
> 
> Upstream as of now (same SHA1 as in linux-next):
> 
> >From 437f88cc031ffe7f37f3e705367f4fe1f4be8b0f Mon Sep 17 00:00:00 2001
> From: Eric Sandeen <sandeen@sandeen.net>
> Date: Sun, 1 Aug 2010 17:33:29 -0400
> Subject: [PATCH] (pre-stable) ext4: fix freeze deadlock under IO

It looks like I can't drop the original one, as this patch builds on it.
So I'll just queue this one up.

Should it also go into other -stable releases (like .35 and/or .34 -stable?)

thanks,

greg k-h

Re: [stable] [Stable-review] [116/165] ext4: dont return to userspace after freezing the fs with a mutex held

[Stefan Bader]

On 08/10/2010 10:16 PM, Greg KH wrote:
> On Mon, Aug 09, 2010 at 11:00:43AM +0200, Stefan Bader wrote:
>> On 08/07/2010 03:38 PM, Eric Sandeen wrote:
>>> Henrique de Moraes Holschuh wrote:
>>>> On Mon, 02 Aug 2010, Greg KH wrote:
>>>>> On Mon, Aug 02, 2010 at 12:02:45PM -0500, Eric Sandeen wrote:
>>>>>> 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...
>>>>> I can't take anything that isn't upstream yet.
>>>>>
>>>>> And I just released with this patch in the kernel, should I do a revert
>>>>> and do a new release?
>>>>
>>>> Any answers on this?
>>>>
>>>
>>> Yes, I'd revert it for now, I'm afraid, if the other patch isn't upstream
>>> yet.
>>>
>>> Sorry about that,
>>>
>>> -Eric
>>
>> Upstream as of now (same SHA1 as in linux-next):
>>
>> >From 437f88cc031ffe7f37f3e705367f4fe1f4be8b0f Mon Sep 17 00:00:00 2001
>> From: Eric Sandeen <sandeen@sandeen.net>
>> Date: Sun, 1 Aug 2010 17:33:29 -0400
>> Subject: [PATCH] (pre-stable) ext4: fix freeze deadlock under IO
> 
> It looks like I can't drop the original one, as this patch builds on it.
> So I'll just queue this one up.
> 
> Should it also go into other -stable releases (like .35 and/or .34 -stable?)
> 

Final call would be Eric/Ted but as far as I can see:

.34: not for now (patch that causes regression not backported there (yet))
.35: yes (offending patch has been in 2.6.35-rc1)

-Stefan

> thanks,
> 
> greg k-h

Re: [stable] [Stable-review] [116/165] ext4: dont return to userspace after freezing the fs with a mutex held

[Eric Sandeen]

Stefan Bader wrote:
> On 08/10/2010 10:16 PM, Greg KH wrote:
>> On Mon, Aug 09, 2010 at 11:00:43AM +0200, Stefan Bader wrote:
>>> On 08/07/2010 03:38 PM, Eric Sandeen wrote:
>>>> Henrique de Moraes Holschuh wrote:
>>>>> On Mon, 02 Aug 2010, Greg KH wrote:
>>>>>> On Mon, Aug 02, 2010 at 12:02:45PM -0500, Eric Sandeen wrote:
>>>>>>> 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...
>>>>>> I can't take anything that isn't upstream yet.
>>>>>>
>>>>>> And I just released with this patch in the kernel, should I do a revert
>>>>>> and do a new release?
>>>>> Any answers on this?
>>>>>
>>>> Yes, I'd revert it for now, I'm afraid, if the other patch isn't upstream
>>>> yet.
>>>>
>>>> Sorry about that,
>>>>
>>>> -Eric
>>> Upstream as of now (same SHA1 as in linux-next):
>>>
>>> >From 437f88cc031ffe7f37f3e705367f4fe1f4be8b0f Mon Sep 17 00:00:00 2001
>>> From: Eric Sandeen <sandeen@sandeen.net>
>>> Date: Sun, 1 Aug 2010 17:33:29 -0400
>>> Subject: [PATCH] (pre-stable) ext4: fix freeze deadlock under IO
>> It looks like I can't drop the original one, as this patch builds on it.
>> So I'll just queue this one up.
>>
>> Should it also go into other -stable releases (like .35 and/or .34 -stable?)
>>
> 
> Final call would be Eric/Ted but as far as I can see:
> 
> .34: not for now (patch that causes regression not backported there (yet))
> .35: yes (offending patch has been in 2.6.35-rc1)

As long as the 2 patches go together it should be fine, I don't think there
are other significant dependencies.

It's also not really an urgent one to fix; returning to userspace w/ a lock
held is pretty icky but in practice has not been an actual problem AFAIK; most
people use lvm to freeze/unfreeze and it all gets cleaned up....

-Eric

> -Stefan
> 
>> thanks,
>>
>> greg k-h
> 

Re: [Stable-review] [stable] [116/165] ext4: dont return to userspace after freezing the fs with a mutex held

[Ted Ts'o]

On Wed, Aug 11, 2010 at 08:20:55AM -0400, Eric Sandeen wrote:
> 
> As long as the 2 patches go together it should be fine, I don't
> think there are other significant dependencies.
> 
> It's also not really an urgent one to fix; returning to userspace w/
> a lock held is pretty icky but in practice has not been an actual
> problem AFAIK; most people use lvm to freeze/unfreeze and it all
> gets cleaned up....

Agreed.

I do plan to be uploading stable updates for 2.6.35.x that include the
changes that got pulled for 2.6.35-rc1, and I'll update 2.6.34 and
2.6.32, as well, with 2.6.34 including the updates that somehow didn't
all make it to stable last time.  (I'm thinking about also including
an ftp upload since for some reason some mail server between me at
stable@kernel.org seems to be dropping mail messages when they get
blasted out using git send-email.  :-/ )

I'm at Linuxcon this week though, so I probably won't get to it until
sometime next week.

					- Ted

Re: [stable] [Stable-review] [116/165] ext4: dont return to userspace after freezing the fs with a mutex held

[Greg KH]

On Mon, Aug 09, 2010 at 11:00:43AM +0200, Stefan Bader wrote:
> On 08/07/2010 03:38 PM, Eric Sandeen wrote:
> > Henrique de Moraes Holschuh wrote:
> >> On Mon, 02 Aug 2010, Greg KH wrote:
> >>> On Mon, Aug 02, 2010 at 12:02:45PM -0500, Eric Sandeen wrote:
> >>>> 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...
> >>> I can't take anything that isn't upstream yet.
> >>>
> >>> And I just released with this patch in the kernel, should I do a revert
> >>> and do a new release?
> >>
> >> Any answers on this?
> >>
> > 
> > Yes, I'd revert it for now, I'm afraid, if the other patch isn't upstream
> > yet.
> > 
> > Sorry about that,
> > 
> > -Eric
> 
> Upstream as of now (same SHA1 as in linux-next):
> 
> >From 437f88cc031ffe7f37f3e705367f4fe1f4be8b0f Mon Sep 17 00:00:00 2001
> From: Eric Sandeen <sandeen@sandeen.net>
> Date: Sun, 1 Aug 2010 17:33:29 -0400
> Subject: [PATCH] (pre-stable) ext4: fix freeze deadlock under IO

That is a patch from 2010, are you sure this is what you are looking
for?

confused,

greg k-h