From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Dave Chinner <david@fromorbit.com>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 19/24] xfs: use bios directly to read and write the log recovery buffers
Date: Tue, 9 Jul 2019 08:44:47 -0700 [thread overview]
Message-ID: <20190709154447.GR1404256@magnolia> (raw)
In-Reply-To: <20190709152330.GA3945@lst.de>
On Tue, Jul 09, 2019 at 05:23:30PM +0200, Christoph Hellwig wrote:
> On Tue, Jul 09, 2019 at 08:15:08AM +1000, Dave Chinner wrote:
> > That fixes the problem I saw, but I think bio_chain() needs some
> > more checks to prevent this happening in future. It's trivially
> > easy to chain the bios in the wrong order, very difficult to spot
> > in review, and difficult to trigger in testing as it requires
> > chain nesting and adverse IO timing to expose....
>
> Not sure how we can better check it. At best we can set a flag for a
> bio that is a chain "child" and complain if someone is calling
> submit_bio_wait, but that would only really cover the wait case.
I think submit_bio_wait ought to at least WARN_ON_ONCE if it was fed a
bio with bi_end_io already set, which at least would have made it more
obvious that we'd screwed something up in this case, even if the
detection was after we'd already done bio_chain in the wrong order.
Granted IIRC Dave sent a fix for a zeroout integer overflow a while ago
and Jens committed the patch with the debugging assertions removed, so
... yay?
Maybe we just need CONFIG_BLK_DEBUG for these kinds of assertions so
that ignorant clods like me have another line of defense against bugs
and the growing crowd of people who care about performance above
correctness can crash faster. <grumble>
> But one thing I planned to do is to lift xfs_chain_bio to the block
> layer so that people can use it for any kind of continuation bio
> instead of duplicating the logic.
That'll help, I suspect. :)
--D
next prev parent reply other threads:[~2019-07-09 15:44 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-05 19:14 use bios directly in the log code v4 Christoph Hellwig
2019-06-05 19:14 ` [PATCH 01/24] xfs: remove the no-op spinlock_destroy stub Christoph Hellwig
2019-06-05 19:14 ` [PATCH 02/24] xfs: remove the never used _XBF_COMPOUND flag Christoph Hellwig
2019-06-05 19:14 ` [PATCH 03/24] xfs: renumber XBF_WRITE_FAIL Christoph Hellwig
2019-06-05 19:14 ` [PATCH 04/24] xfs: make mem_to_page available outside of xfs_buf.c Christoph Hellwig
2019-06-05 19:14 ` [PATCH 05/24] xfs: remove the l_iclog_size_log field from strut xlog Christoph Hellwig
2019-06-05 21:17 ` Dave Chinner
2019-06-17 23:08 ` Darrick J. Wong
2019-06-05 19:14 ` [PATCH 06/24] xfs: cleanup xlog_get_iclog_buffer_size Christoph Hellwig
2019-06-05 21:21 ` Dave Chinner
2019-06-05 19:14 ` [PATCH 07/24] xfs: reformat xlog_get_lowest_lsn Christoph Hellwig
2019-06-05 19:14 ` [PATCH 08/24] xfs: remove XLOG_STATE_IOABORT Christoph Hellwig
2019-06-06 0:13 ` Dave Chinner
2019-06-05 19:14 ` [PATCH 09/24] xfs: don't use REQ_PREFLUSH for split log writes Christoph Hellwig
2019-06-05 19:14 ` [PATCH 10/24] xfs: factor out log buffer writing from xlog_sync Christoph Hellwig
2019-06-05 19:14 ` [PATCH 11/24] xfs: factor out splitting of an iclog " Christoph Hellwig
2019-06-05 19:14 ` [PATCH 12/24] xfs: factor out iclog size calculation " Christoph Hellwig
2019-06-05 19:15 ` [PATCH 13/24] xfs: update both stat counters together in xlog_sync Christoph Hellwig
2019-06-05 19:15 ` [PATCH 14/24] xfs: remove the syncing argument from xlog_verify_iclog Christoph Hellwig
2019-06-05 19:15 ` [PATCH 15/24] xfs: make use of the l_targ field in struct xlog Christoph Hellwig
2019-06-05 19:15 ` [PATCH 16/24] xfs: use bios directly to write log buffers Christoph Hellwig
2019-06-17 23:27 ` Darrick J. Wong
2019-06-18 5:58 ` Christoph Hellwig
2019-06-05 19:15 ` [PATCH 17/24] xfs: move the log ioend workqueue to struct xlog Christoph Hellwig
2019-06-05 19:15 ` [PATCH 18/24] xfs: return an offset instead of a pointer from xlog_align Christoph Hellwig
2019-06-05 19:15 ` [PATCH 19/24] xfs: use bios directly to read and write the log recovery buffers Christoph Hellwig
2019-07-08 7:37 ` Dave Chinner
2019-07-08 16:19 ` Darrick J. Wong
2019-07-08 16:24 ` Christoph Hellwig
2019-07-08 21:34 ` Christoph Hellwig
2019-07-08 22:15 ` Dave Chinner
2019-07-09 15:23 ` Christoph Hellwig
2019-07-09 15:44 ` Darrick J. Wong [this message]
2019-06-05 19:15 ` [PATCH 20/24] xfs: stop using bp naming for " Christoph Hellwig
2019-06-05 19:15 ` [PATCH 21/24] xfs: remove unused buffer cache APIs Christoph Hellwig
2019-06-05 19:15 ` [PATCH 22/24] xfs: properly type the b_log_item field in struct xfs_buf Christoph Hellwig
2019-06-05 19:15 ` [PATCH 23/24] xfs: remove the b_io_length " Christoph Hellwig
2019-06-05 19:15 ` [PATCH 24/24] xfs: add struct xfs_mount pointer to " Christoph Hellwig
2019-06-17 23:30 ` use bios directly in the log code v4 Darrick J. Wong
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=20190709154447.GR1404256@magnolia \
--to=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=hch@lst.de \
--cc=linux-xfs@vger.kernel.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 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.