All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Brian Foster <bfoster@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>, xfs@oss.sgi.com
Subject: Re: [PATCH 3/3] xfs: optimize bio handling in the buffer writeback path
Date: Fri, 11 Mar 2016 16:06:06 +0100	[thread overview]
Message-ID: <20160311150606.GA3016@lst.de> (raw)
In-Reply-To: <20160304133854.GB3758@bfoster.bfoster>

On Fri, Mar 04, 2016 at 08:38:55AM -0500, Brian Foster wrote:
> One thing I'm a bit suspicious about still is whether the error
> propagation is racy. For example, consider we've created two chained
> bios A and B, such that A is the parent and thus bio(io_remaining) for
> each is A(2) and B(1). Suppose bio A happens to complete first with an
> error. A->bi_error is set and bio_endio(A) is called, which IIUC
> basically just does A(2)->A(1). If bio B completes successfully,
> B->bi_error presumably remains set to 0 and bio_endio(B) is called. The
> latter checks that B->bi_end_io == bio_chain_endio, propagates
> B->bi_error to A->bi_error unconditionally and then walks up to the
> parent bio to drop its reference and finally call A->bi_end_io().
> 
> Doesn't this mean that we can potentially lose errors in the chain? I
> could easily still be missing something here...

Yes, it looks like bio_chain_endio and bio_endio should be fixed
to only set parent->bi_error if it's not already set.  I'll send a 
patch.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2016-03-11 15:06 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-24  8:20 futher writeback updates Christoph Hellwig
2016-02-24  8:20 ` [PATCH 1/3] xfs: build bios directly in xfs_add_to_ioend Christoph Hellwig
2016-03-03 15:17   ` Brian Foster
2016-02-24  8:20 ` [PATCH 2/3] xfs: don't release bios on completion immediately Christoph Hellwig
2016-03-03 15:17   ` Brian Foster
2016-03-11 14:47     ` Christoph Hellwig
2016-03-11 17:52       ` Brian Foster
2016-02-24  8:20 ` [PATCH 3/3] xfs: optimize bio handling in the buffer writeback path Christoph Hellwig
2016-03-03 15:17   ` Brian Foster
2016-03-04 13:38     ` Brian Foster
2016-03-11 15:06       ` Christoph Hellwig [this message]
2016-03-11 14:55     ` Christoph Hellwig
2016-03-01 13:01 ` futher writeback updates Christoph Hellwig
2016-03-01 21:42   ` Dave Chinner
  -- strict thread matches above, loose matches on Subject: below --
2016-03-16 11:44 further writeback updates V2 Christoph Hellwig
2016-03-16 11:44 ` [PATCH 3/3] xfs: optimize bio handling in the buffer writeback path Christoph Hellwig
2016-03-17 13:05   ` Brian Foster
2016-05-31 15:35   ` Eric Sandeen
2016-05-31 16:31     ` Christoph Hellwig
2016-05-31 16:44       ` Eric Sandeen
2016-05-31 17:35         ` Eric Sandeen

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=20160311150606.GA3016@lst.de \
    --to=hch@lst.de \
    --cc=bfoster@redhat.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 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.