All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Jan Kara <jack@suse.cz>
Cc: Mateusz Guzik <mguzik@redhat.com>,
	Pierre Morel <pmorel@linux.vnet.ibm.com>,
	viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, farman@linux.vnet.ibm.com,
	cornelia.huck@de.ibm.com, Jens Axboe <axboe@fb.com>,
	Josef Bacik <jbacik@fb.com>
Subject: Re: [PATCH] fs/block_dev.c: return the right error in thaw_bdev()
Date: Thu, 6 Oct 2016 07:21:58 +1100	[thread overview]
Message-ID: <20161005202158.GA9806@dastard> (raw)
In-Reply-To: <20161005095903.GC7291@quack2.suse.cz>

On Wed, Oct 05, 2016 at 11:59:03AM +0200, Jan Kara wrote:
> On Wed 05-10-16 08:47:42, Mateusz Guzik wrote:
> > On Tue, Oct 04, 2016 at 11:06:15AM +0200, Jan Kara wrote:
> > > On Tue 04-10-16 10:53:40, Pierre Morel wrote:
> > > > When triggering thaw-filesystems via magic sysrq, the system enters a
> > > > loop in do_thaw_one(), as thaw_bdev() still returns success if
> > > > bd_fsfreeze_count == 0. To fix this, let thaw_bdev() always return
> > > > error (and simplify the code a bit at the same time).
> > > > 
> > > 
> > > The patch looks good.
> > > 
> > 
> > Now that I had a closer look, while the patch indeed gets rid of the
> > infinite loop, the functionality itself does not work properly.
> > 
> > Note I'm not familiar with this code, so chances are I got details
> > wrong. I also don't know the original reasoning.
> > 
> > The current state is that you can freeze by calling either freeze_super
> > or freeze_bdev. The latter bumps bd_fsfreeze_count and calls
> > freeze_super. freeze_super does NOT modify bd_fsfreeze_count.
> > 
> > freeze_bdev is used by device mapper, xfs and e2fs.
> 
> Where is freeze_bdev() used by e2fs?

typo - it's f2fs, and it's usage is copied from XFS. Both of those
usages can be completely ignored for th purposes of this argument,
because they are done in the context of {X,F2}FS_IOC_FSGOINGDOWN.
i.e ioctls to shutdown a filesystem and completely deny access to
it. Freezing is just means to an end - it's just used to prevent any
more IO from being issued by the block device while we do the
filesystem shutdown...

IOWs, These are never used in normal usage by users - they are a
diagnostic tool and, potentially, a get-out-of-gaol-free card that
can be played when something goes wrong with the underlying storage
and the filesystem hangs waiting for it.

Indeed, the code in both does:

	sb = freeze_bdev()
	if (sb && !IS_ERR(sb) {
		do_shutdown()
		thaw_bdev(sb)
	}

Which is perfectly sane and will not cause any sort of unbalanced
freeze behaviour to occur unless the shutdown oopses, in which case
the user has bigger problems than a frozen device...

So in production systems, dm_suspend()->lock_fs()->freeze_bdev() is
the only path that will ever be exercised.

> > Now, looking at *_bdev functions:
> > 
> > > struct super_block *freeze_bdev(struct block_device *bdev)
> > > {       
> > >         struct super_block *sb;
> > >         int error = 0;
> > >         
> > >         mutex_lock(&bdev->bd_fsfreeze_mutex);
> > >         if (++bdev->bd_fsfreeze_count > 1) {
> > 
> > No limit is put in place so in principle this will eventually turn negative.
> 
> Yeah, ok, send a fix...

FWIW, that will only overflow if someone tries to freeze their block
device more than *2 billion times* without a thaw. If that happens,
the user has bigger problems to worry about, like the days/weeks the
system couldn't write to the filesystem because it was frozen.... :/

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2016-10-05 20:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-04  8:53 [PATCH] return the right error in thaw_bdev() Pierre Morel
2016-10-04  8:53 ` [PATCH] fs/block_dev.c: " Pierre Morel
2016-10-04  9:06   ` Jan Kara
2016-10-05  6:47     ` Mateusz Guzik
2016-10-05  9:59       ` Jan Kara
2016-10-05 20:21         ` Dave Chinner [this message]
2016-10-05 20:35     ` Jens Axboe

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=20161005202158.GA9806@dastard \
    --to=david@fromorbit.com \
    --cc=axboe@fb.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=farman@linux.vnet.ibm.com \
    --cc=jack@suse.cz \
    --cc=jbacik@fb.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mguzik@redhat.com \
    --cc=pmorel@linux.vnet.ibm.com \
    --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.