mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ming Lei <ming.lei@canonical.com>
To: Mike Snitzer <snitzer@redhat.com>
Cc: Josh Boyer <jwboyer@fedoraproject.org>,
	ejt@redhat.com, Johannes Weiner <hannes@cmpxchg.org>,
	Tejun Heo <tj@kernel.org>, Jens Axboe <axboe@fb.com>,
	"Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
	mlin@kernel.org, awilliam@redhat.com, tom.leiming@gmail.com
Subject: Re: 32-bit bio regression with 4.3 [was: Re: cgroup/loop Bad page state oops in Linux v4.2-rc3-136-g45b4b782e848]
Date: Sat, 12 Sep 2015 21:19:32 +0800	[thread overview]
Message-ID: <20150912211932.6c2b364d@tom-T450> (raw)
In-Reply-To: <20150911214315.GA26995@redhat.com>

On Fri, 11 Sep 2015 17:43:15 -0400
Mike Snitzer <snitzer@redhat.com> wrote:

> Ming, Jens, others:
> 
> Please see this BZ comment that speaks to a 4.3 regression due to the
> late bio splitting changes:
> https://bugzilla.redhat.com/show_bug.cgi?id=1247382#c41

I think it is a bug of bounce_end_io, and the following patch may
fix it.

----
>From 08df0db0be41e6bea306bcf5b4d325f5a79dc7a1 Mon Sep 17 00:00:00 2001
From: Ming Lei <ming.lei@canonical.com>
Date: Sat, 12 Sep 2015 20:48:42 +0800
Subject: [PATCH] block: fix bounce_end_io

When bio bounce is involved, one new bio and its io vector are
cloned from the coming bio, which can be one fast-cloned bio
and its io vector can be shared with another bio too, especially
after bio_split() is introduced.

So it is obviously wrong to assume the start index of the original
bio's io vector is zero, which can be any value between 0 and
(bi_max_vecs - 1), especially in case of bio split.

Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
 block/bounce.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/block/bounce.c b/block/bounce.c
index 0611aea..1cb5dd3 100644
--- a/block/bounce.c
+++ b/block/bounce.c
@@ -128,12 +128,14 @@ static void bounce_end_io(struct bio *bio, mempool_t *pool)
 	struct bio *bio_orig = bio->bi_private;
 	struct bio_vec *bvec, *org_vec;
 	int i;
+	int start = bio_orig->bi_iter.bi_idx;
 
 	/*
 	 * free up bounce indirect pages used
 	 */
 	bio_for_each_segment_all(bvec, bio, i) {
-		org_vec = bio_orig->bi_io_vec + i;
+		org_vec = bio_orig->bi_io_vec + i + start;
+
 		if (bvec->bv_page == org_vec->bv_page)
 			continue;
 
-- 
1.9.1

> But inlined here so we can continue on list:
> (In reply to Josh Boyer from comment #40)
> > The function that was fixed in 4.2 doesn't exist any longer in
> > 4.3.0-0.rc0.git6.1.fc24.  That kernel corresponds to Linux
> > v4.2-6105-gdd5cdb48edfd which contains commit
> > 8ae126660fddbeebb9251a174e6fa45b6ad8f932, which removed it completely.  So
> > whatever fix was made in dm_merge_bvec doesn't seem to have made it to
> > whatever replaced it.
> 
> The dm core fix to dm_merge_bvec was commit bd4aaf8f9b ("dm: fix
> dm_merge_bvec regression on 32 bit systems").  But I'm not sure there is
> a clear equivalent in the late bio splitting code that replaced block
> core's merge_bvec logic.
> 
> merge_bvec was all about limiting bios (by asking "can/should this page
> be added to this bio?") whereas the late bio splitting is more "build
> the bios as large as possible and worry about splitting later".

IMO, given one vector can only point to one page, there shouldn't
have difference between the two.

> 
> Regardless, this regression needs to be reported to Ming Lin
> <ming.l@ssi.samsung.com>, Jens Axboe and the others involved in
> maintaining the late bio splitting changes in block core.
> 
> Josh and/or Adam: it would _really_ help if the regression test you guys
> are using could be handed-over and/or explained to us.  Is it as simple
> as loading a 32bit with a particular config?  Can you share the guest
> image if it is small enough?

Josh, Adam, would you mind testing the above patch to see if it can fix
your issue?

Thanks,
Ming

> 
> Mike
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


  parent reply	other threads:[~2015-09-12 13:19 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-29 13:27 cgroup/loop Bad page state oops in Linux v4.2-rc3-136-g45b4b782e848 Josh Boyer
2015-07-29 13:51 ` Johannes Weiner
2015-07-29 15:32   ` Ming Lei
2015-07-29 16:36     ` Josh Boyer
2015-07-30  0:29       ` Ming Lei
2015-07-30 11:27         ` Josh Boyer
2015-07-30 23:14           ` Josh Boyer
2015-07-31  0:19             ` Mike Snitzer
2015-07-31 18:58               ` Josh Boyer
2015-08-02 14:01                 ` Josh Boyer
2015-08-03 14:28                   ` Mike Snitzer
2015-08-03 16:56                     ` Josh Boyer
2015-08-04  1:11                       ` Josh Boyer
2015-09-11 21:43                         ` 32-bit bio regression with 4.3 [was: Re: cgroup/loop Bad page state oops in Linux v4.2-rc3-136-g45b4b782e848] Mike Snitzer
2015-09-11 21:50                           ` Adam Williamson
2015-09-12  4:43                           ` Ming Lin
2015-09-12  7:34                             ` Ming Lin
2015-09-12  7:52                               ` Ming Lin
2015-09-12 13:19                           ` Ming Lei [this message]
2015-09-15 12:14                             ` Josh Boyer
2015-09-16 17:56                               ` Josh Boyer
2015-09-17 15:24                                 ` Adam Williamson
2015-09-17 15:51                                   ` Ming Lei

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=20150912211932.6c2b364d@tom-T450 \
    --to=ming.lei@canonical.com \
    --cc=awilliam@redhat.com \
    --cc=axboe@fb.com \
    --cc=ejt@redhat.com \
    --cc=hannes@cmpxchg.org \
    --cc=jwboyer@fedoraproject.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mlin@kernel.org \
    --cc=snitzer@redhat.com \
    --cc=tj@kernel.org \
    --cc=tom.leiming@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®