From: Kent Overstreet <kent.overstreet@gmail.com>
To: Ming Lei <tom.leiming@gmail.com>
Cc: Ming Lin <mlin@kernel.org>, Jens Axboe <axboe@kernel.dk>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
torvalds@linux-foundation.org
Subject: Re: e827091cb1 "block: merge: get the 1st and last bvec via helpers" broken
Date: Sat, 12 Mar 2016 05:36:12 -0900 [thread overview]
Message-ID: <20160312143612.GA30418@kmo-pixel> (raw)
In-Reply-To: <20160312222548.6a81d13b@tom-T450>
On Sat, Mar 12, 2016 at 10:25:48PM +0800, Ming Lei wrote:
> On Sat, 12 Mar 2016 05:02:56 -0900
> Kent Overstreet <kent.overstreet@gmail.com> wrote:
>
> > Here's the output of the patch below:
> >
> > generic/036 11s ...run fstests generic/036 at 2016-03-12 13:58:21
> > end 4096 0 ffffea0001d611c0 end2 1024 0 ffffea0001d611c0
> > len 1024 offset 0 page ffffea0001d611c0
> > KGDB: Waiting for remote debugger
> >
> > Your code gives a biovec with bv_len of 4096, the old code gives a biovec with
> > bv_len of 1024 (and then we dump every biovec, we see that the bio had only a
> > single biovec that did indeed have bv_len == 1024).
>
> I guess we shouldn't have optimized for the case of non-cloned bio, could you
> try the following patch?
>
> --
> diff --git a/include/linux/bio.h b/include/linux/bio.h
> index 1e7248f..4abc129 100644
> --- a/include/linux/bio.h
> +++ b/include/linux/bio.h
> @@ -267,11 +267,6 @@ static inline void bio_get_last_bvec(struct bio *bio, struct bio_vec *bv)
> struct bvec_iter iter = bio->bi_iter;
> int idx;
>
> - if (!bio_flagged(bio, BIO_CLONED)) {
> - *bv = bio->bi_io_vec[bio->bi_vcnt - 1];
> - return;
> - }
> -
> if (unlikely(!bio_multiple_segments(bio))) {
> *bv = bio_iovec(bio);
> return;
>
> Thanks,
> Ming
Yes, that's it.
!BIO_CLONED is _not_ a guarantee that bi_size doesn't straddle the middle of a
bvec - bcachefs was hitting this by bouncing a bio that had already been split
(which can happen elsewhere in the kernel...) but there's other (perfectly
legal) ways it can happen.
I would still strongly suggest reverting the patch for 4.5 and resubmitting
during the next merge window.
next prev parent reply other threads:[~2016-03-12 14:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-12 7:43 e827091cb1 "block: merge: get the 1st and last bvec via helpers" broken Kent Overstreet
2016-03-12 8:04 ` Ming Lin
2016-03-12 8:49 ` Ming Lei
2016-03-12 9:24 ` Kent Overstreet
2016-03-12 10:36 ` Ming Lei
2016-03-12 12:12 ` Kent Overstreet
2016-03-12 13:33 ` Ming Lei
2016-03-12 13:48 ` Kent Overstreet
2016-03-12 14:02 ` Kent Overstreet
2016-03-12 14:25 ` Ming Lei
2016-03-12 14:36 ` Kent Overstreet [this message]
2016-03-12 14:39 ` Ming Lei
2016-03-12 19:51 ` Linus Torvalds
2016-03-12 21:14 ` Jens Axboe
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=20160312143612.GA30418@kmo-pixel \
--to=kent.overstreet@gmail.com \
--cc=axboe@kernel.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=mlin@kernel.org \
--cc=tom.leiming@gmail.com \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox