All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Dave Chinner <david@fromorbit.com>
Cc: Jeffrey Merkey <jeffmerkey@gmail.com>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	josef@redhat.com, viro@zeniv.linux.org.uk
Subject: Re: 2.6.34 echo j > /proc/sysrq-trigger causes inifnite unfreeze/Thaw event
Date: Sun, 06 Jun 2010 23:23:36 -0500	[thread overview]
Message-ID: <4C0C7448.7040409@sandeen.net> (raw)
In-Reply-To: <20100607010542.GB27325@dastard>

Dave Chinner wrote:
> On Thu, Jun 03, 2010 at 11:30:30PM -0600, Jeffrey Merkey wrote:
>> causes the FS Thaw stuff in fs/buffer.c to enter an infinite loop
>> filling the /var/log/messages with junk and causing the hard drive to
>> crank away endlessly.
> 
> Hmmm, looks pretty obvious what the 2.6.34 bug is:
> 
>         while (sb->s_bdev && !thaw_bdev(sb->s_bdev, sb))
>                 printk(KERN_WARNING "Emergency Thaw on %s\n",
>                        bdevname(sb->s_bdev, b));
> 
> thaw_bdev() returns 0 on success or not frozen, and returns non-zero
> only if the unfreeze failed. Looks like it was broken from the start
> to me.

thaw_bdev() used to return -EINVAL for not-frozen, but it no longer
does.  Seems commit 4504230a dropped this:

-       if (!bdev->bd_fsfreeze_count) {
-               mutex_unlock(&bdev->bd_fsfreeze_mutex);
-               return -EINVAL;
-       }

in favor of this:

+       int error = -EINVAL;
...
+       if (!bdev->bd_fsfreeze_count)
+               goto out_unlock;
...
+out_unlock:
        mutex_unlock(&bdev->bd_fsfreeze_mutex);
        return 0;

and now we return 0 for a thaw of a non-frozen bdev ....
this breaks the loop in the emergency thaw-er (which was
just supposed to work its way through nested freezes,
when I wrote it)

-Eric

  reply	other threads:[~2010-06-07  4:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-04  5:30 2.6.34 echo j > /proc/sysrq-trigger causes inifnite unfreeze/Thaw event Jeffrey Merkey
2010-06-07  1:05 ` Dave Chinner
2010-06-07  4:23   ` Eric Sandeen [this message]
2010-06-07 21:36   ` Josef Bacik
2010-06-07 21:59     ` Josef Bacik
2010-06-07 23:23       ` Dave Chinner
2010-06-08  2:07         ` Josef Bacik
2010-06-08  2:26           ` Dave Chinner
2010-06-08 12:58             ` Dave Chinner
2010-06-08 14:56               ` Josef Bacik

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=4C0C7448.7040409@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=david@fromorbit.com \
    --cc=jeffmerkey@gmail.com \
    --cc=josef@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.