xfs
[Top] [All Lists]

Re: [PATCH 3/3] xfs: optimize bio handling in the buffer writeback path

To: Brian Foster <bfoster@xxxxxxxxxx>
Subject: Re: [PATCH 3/3] xfs: optimize bio handling in the buffer writeback path
From: Christoph Hellwig <hch@xxxxxx>
Date: Fri, 11 Mar 2016 16:06:06 +0100
Cc: Christoph Hellwig <hch@xxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20160304133854.GB3758@xxxxxxxxxxxxxxx>
References: <1456302011-18915-1-git-send-email-hch@xxxxxx> <1456302011-18915-4-git-send-email-hch@xxxxxx> <20160303151730.GC57990@xxxxxxxxxxxxxxx> <20160304133854.GB3758@xxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.17 (2007-11-01)
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.

<Prev in Thread] Current Thread [Next in Thread>