From: Dave Chinner <david@fromorbit.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: XFS Developers <xfs@oss.sgi.com>,
linux-block@vger.kernel.org,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
Jens Axboe <axboe@fb.com>, Jan Kara <jack@suse.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Matthew Wilcox <willy@linux.intel.com>,
Ross Zwisler <ross.zwisler@linux.intel.com>
Subject: Re: [resend PATCH 1/3] block, fs: reliably communicate bdev end-of-life
Date: Wed, 6 Jan 2016 09:32:36 +1100 [thread overview]
Message-ID: <20160105223236.GD21461@dastard> (raw)
In-Reply-To: <CAPcyv4i=5-e6mobC5yu1SgESBNgCeqU5jwbaxhN8ZmNW+xUnJA@mail.gmail.com>
On Mon, Jan 04, 2016 at 08:25:16PM -0800, Dan Williams wrote:
> On Mon, Jan 4, 2016 at 7:51 PM, Dave Chinner <david@fromorbit.com> wrote:
> > On Mon, Jan 04, 2016 at 10:20:05AM -0800, Dan Williams wrote:
> >> Historically we have waited for filesystem specific heuristics to
> >> attempt to guess when a block device is gone. Sometimes this works, but
> >> in other cases the system can hang waiting for the fs to trigger its
> >> shutdown protocol.
....
> True, and following this logic I think the existing
> generic_shutdown_super() should be renamed generic_kill_super() to
> match the fs actions, but see below...
>
> > Operation methods should be named after what they do, not what their
> > calling context is. i.e. these are "invalidate" and "shutdown"
> > superblock operations, not "quiesce" and "bdi_gone".
>
> I was running out of colors to paint the bike shed given
> generic_shutdown_super() was already in use. Also, since
Ah, yeah, i forgot about that function. To many different shades of
purple are already in use. :/
> >> +void shutdown_partition(struct gendisk *disk, int partno)
> >> +{
> >> + struct block_device *bdev = bdget_disk(disk, partno);
> >> + struct super_block *sb = get_super(bdev);
> >> +
> >> + if (!bdev)
> >> + return;
> >
> > Null pointer deref. Certainly a landmine waiting for someone to
> > tread on.
> >
>
> Nope, get_super() checks for a NULL argument.
Hence my comment about it being a landmine. If get_super() is ever
changed, this code will explode on us when we least expect it. If I
have to go read other code in a completely different file just to
determine the code is actually safe, then I consider that bad code.
Code that is slightly more verbose but is obviously correct and
balanced is much, much easier to understand and maintain....
> >> + if (!sb) {
> >> + bdput(bdev);
> >> + return;
> >> + }
> >> +
> >> + if (sb->s_op->bdi_gone)
> >> + sb->s_op->bdi_gone(sb);
> >> + else
> >> + generic_bdi_gone(sb);
> >
> > if (sb->s_op->shutdown)
> > sb->s_op->shutdown(sb);
> > else
> > unmap_dax_inodes(sb);
> >
> > name things correctly, and the code documents itself.
>
> How about 'stop' or 'halt' instead of 'shutdown' to preserve the
> historical meaning of generic_shutdown_super?
It's hard chosing a different color that is appropriate. :/
Because it's a brute-force behavioural override, I think that needs
to be obvious from the op name. So something like force_stop or
force_failure seems best to me.
In fact, now that I've thought/repaeated/written force_failure a
couple of times, it seems quite appropriate here, as what we want to
be able to do is force the filesystem into a (permanent) failure
state.....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2016-01-05 22:32 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-04 18:20 [resend PATCH 0/3] fs, bdev: handle end of life Dan Williams
2016-01-04 18:20 ` [resend PATCH 1/3] block, fs: reliably communicate bdev end-of-life Dan Williams
2016-01-05 3:51 ` Dave Chinner
2016-01-05 4:25 ` Dan Williams
2016-01-05 22:32 ` Dave Chinner [this message]
2016-01-09 7:54 ` Al Viro
2016-01-09 14:17 ` Dan Williams
2016-01-11 7:15 ` Hannes Reinecke
2016-01-11 15:24 ` Hannes Reinecke
2016-01-11 15:55 ` Dan Williams
2016-01-04 18:20 ` [resend PATCH 2/3] xfs: handle shutdown notifications Dan Williams
2016-01-05 4:03 ` Dave Chinner
2016-01-04 18:20 ` [resend PATCH 3/3] writeback: fix false positive WARN in __mark_inode_dirty Dan Williams
2016-01-05 4:23 ` Dave Chinner
2016-01-05 19:59 ` Dan Williams
2016-01-05 21:10 ` Dave Chinner
2016-01-05 21:29 ` Dan Williams
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=20160105223236.GD21461@dastard \
--to=david@fromorbit.com \
--cc=axboe@fb.com \
--cc=dan.j.williams@intel.com \
--cc=jack@suse.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=ross.zwisler@linux.intel.com \
--cc=willy@linux.intel.com \
--cc=xfs@oss.sgi.com \
/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).