From: Christoph Hellwig <hch@lst.de>
To: Mike Snitzer <snitzer@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
linux-raid@vger.kernel.org, dm-devel@redhat.com,
linux-btrfs@vger.kernel.org
Subject: Re: block: add a bi_error field to struct bio
Date: Thu, 11 Jun 2015 09:53:27 +0200 [thread overview]
Message-ID: <20150611075327.GA2113@lst.de> (raw)
In-Reply-To: <20150610152649.GA31140@redhat.com>
On Wed, Jun 10, 2015 at 11:26:49AM -0400, Mike Snitzer wrote:
> Unfortunately by dropping the original error (e.g. -EREMOTEIO) on the
> floor (in the 'if (endio) {' branch) you're breaking the REQ_WRITE_SAME
> check.
I think this also happens in the old code before my patch, e.g.:
static void clone_endio(struct bio *bio, int error)
{
int r = error;
...
if (endio) {
r = endio(tio->ti, bio, error);
...
}
if (unlikely(r == -EREMOTEIO && (bio->bi_rw & REQ_WRITE_SAME) &&
so we already check the return value that comes from the endio handler,
not any different from my patch.
In the original code r and error are basically always the same, execept
after this:
if (!bio_flagged(bio, BIO_UPTODATE) && !error)
error = -EIO;
error might be -EIO and r might be 0. Now if we take the endio branch
we replace both error and r with the return value of endio for all
branches that don't immediately return or BUG(). For the non
endio branch we might check in REQ_WRITE_SAME branch, but r can
only be -EREMOTEIO if it got that value from error, so it doesn't
matter which one we test there.
Based on that I'm pretty sure my prep patch is transformation that
does not change behavior.
next prev parent reply other threads:[~2015-06-11 7:53 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-03 13:42 [RFC] add a bi_error field Christoph Hellwig
2015-06-03 13:42 ` [PATCH] block: add a bi_error field to struct bio Christoph Hellwig
2015-06-04 9:53 ` [dm-devel] " Martin K. Petersen
2015-06-04 15:31 ` Mike Snitzer
2015-06-10 8:11 ` Christoph Hellwig
2015-06-10 8:11 ` Christoph Hellwig
2015-06-10 15:26 ` Mike Snitzer
2015-06-10 15:26 ` Mike Snitzer
2015-06-10 16:01 ` Mike Snitzer
2015-06-10 16:04 ` Christoph Hellwig
2015-06-10 16:50 ` Mike Snitzer
2015-06-10 18:29 ` anup modak
2015-06-11 7:53 ` Christoph Hellwig [this message]
2015-06-11 7:59 ` Christoph Hellwig
2015-06-10 2:50 ` [dm-devel] [PATCH] " Neil Brown
2015-06-10 8:45 ` Christoph Hellwig
2015-06-11 7:59 ` [RFC] add a bi_error field Liu Bo
2015-06-11 8:05 ` Liu Bo
2015-06-11 8:08 ` Christoph Hellwig
2015-06-11 9:42 ` Liu Bo
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=20150611075327.GA2113@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=dm-devel@redhat.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=snitzer@redhat.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.