Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1223113 > unrolled thread

32-bit bio regression with 4.3 [was: Re: cgroup/loop Bad page state oops in Linux v4.2-rc3-136-g45b4b782e848]

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  32-bit bio regression with 4.3 [was: Re: cgroup/loop Bad page state  oops in Linux v4.2-rc3-136-g45b4b782e848] Mike Snitzer <snitzer@redhat.com> - 2015-09-11 23:50 +0200
    Re: 32-bit bio regression with 4.3 [was: Re: cgroup/loop Bad page  state oops in Linux v4.2-rc3-136-g45b4b782e848] Adam Williamson <awilliam@redhat.com> - 2015-09-12 00:00 +0200
    Re: 32-bit bio regression with 4.3 [was: Re: cgroup/loop Bad page  state oops in Linux v4.2-rc3-136-g45b4b782e848] Ming Lin <mlin@kernel.org> - 2015-09-12 06:50 +0200
      Re: 32-bit bio regression with 4.3 [was: Re: cgroup/loop Bad page  state oops in Linux v4.2-rc3-136-g45b4b782e848] Ming Lin <mlin@kernel.org> - 2015-09-12 09:40 +0200
        Re: 32-bit bio regression with 4.3 [was: Re: cgroup/loop Bad page  state oops in Linux v4.2-rc3-136-g45b4b782e848] Ming Lin <mlin@kernel.org> - 2015-09-12 10:00 +0200
    Re: 32-bit bio regression with 4.3 [was: Re: cgroup/loop Bad page  state oops in Linux v4.2-rc3-136-g45b4b782e848] Ming Lei <ming.lei@canonical.com> - 2015-09-12 15:20 +0200
      Re: 32-bit bio regression with 4.3 [was: Re: cgroup/loop Bad page  state oops in Linux v4.2-rc3-136-g45b4b782e848] Josh Boyer <jwboyer@fedoraproject.org> - 2015-09-15 14:20 +0200
        Re: 32-bit bio regression with 4.3 [was: Re: cgroup/loop Bad page  state oops in Linux v4.2-rc3-136-g45b4b782e848] Josh Boyer <jwboyer@fedoraproject.org> - 2015-09-16 20:00 +0200
          Re: 32-bit bio regression with 4.3 [was: Re: cgroup/loop Bad page  state oops in Linux v4.2-rc3-136-g45b4b782e848] Adam Williamson <awilliam@redhat.com> - 2015-09-17 17:30 +0200
            Re: 32-bit bio regression with 4.3 [was: Re: cgroup/loop Bad page  state oops in Linux v4.2-rc3-136-g45b4b782e848] Ming Lei <ming.lei@canonical.com> - 2015-09-17 18:00 +0200

#1223113 — 32-bit bio regression with 4.3 [was: Re: cgroup/loop Bad page state oops in Linux v4.2-rc3-136-g45b4b782e848]

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

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".

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?

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/

[toc] | [next] | [standalone]

#1223118 — Re: 32-bit bio regression with 4.3 [was: Re: cgroup/loop Bad page state oops in Linux v4.2-rc3-136-g45b4b782e848]

On Fri, 2015-09-11 at 17:43 -0400, Mike Snitzer wrote:

> 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?

The test is 'grab a Fedora 32-bit nightly boot.iso (network install)
image and try and boot it'. You can watch it failing in glorious video
technicolor here (the video is sped up, but you can step through frame-
by-frame to catch the errors):

https://openqa.happyassassin.net/tests/4631/file/video.ogv

you can download an affected image here:

https://kojipkgs.fedoraproject.org/mash/rawhide-20150911/rawhide/i386/os/images/boot.iso

I guess strictly speaking we're only sure it fails when booted in a
qemu-kvm VM, but I think we did hit the previous incarnation in bare
metal testing too (so far I haven't tried the 4.3 incarnation on
metal).

we don't keep the nightly ISOs around forever, but it'll be there for
at least a couple of weeks.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


--
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/

[toc] | [prev] | [next] | [standalone]

#1223309 — Re: 32-bit bio regression with 4.3 [was: Re: cgroup/loop Bad page state oops in Linux v4.2-rc3-136-g45b4b782e848]

On Fri, Sep 11, 2015 at 2:43 PM, 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
>
> 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".
>
> 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.

I'm looking at it now.
--
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/

[toc] | [prev] | [next] | [standalone]

#1223329 — Re: 32-bit bio regression with 4.3 [was: Re: cgroup/loop Bad page state oops in Linux v4.2-rc3-136-g45b4b782e848]

On Fri, 2015-09-11 at 21:43 -0700, Ming Lin wrote:
> On Fri, Sep 11, 2015 at 2:43 PM, 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
> >
> > 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".
> >
> > 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.
> 
> I'm looking at it now.

I tried rawhide-20150903 boot.iso and rawhide-20150904 boot.iso.
0903 boot.iso is OK, but 0904 boot.iso just stuck at "Reached target
Basic System". So I can't see the panic.
http://www.minggr.net/pub/20150912/rawhide-20150904-boot.iso.png

I'll run test on 32bit VM, see if I can reproduce the bug.

Adam,

Could you also help to confirm that commit 7140aaf is OK and commit
8ae1266 is bad?

Thanks,
Ming


--
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/

[toc] | [prev] | [next] | [standalone]

#1223330 — Re: 32-bit bio regression with 4.3 [was: Re: cgroup/loop Bad page state oops in Linux v4.2-rc3-136-g45b4b782e848]

On Sat, Sep 12, 2015 at 12:34 AM, Ming Lin <mlin@kernel.org> wrote:
> On Fri, 2015-09-11 at 21:43 -0700, Ming Lin wrote:
>> On Fri, Sep 11, 2015 at 2:43 PM, 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
>> >
>> > 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".
>> >
>> > 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.
>>
>> I'm looking at it now.
>
> I tried rawhide-20150903 boot.iso and rawhide-20150904 boot.iso.
> 0903 boot.iso is OK, but 0904 boot.iso just stuck at "Reached target
> Basic System". So I can't see the panic.
> http://www.minggr.net/pub/20150912/rawhide-20150904-boot.iso.png
>
> I'll run test on 32bit VM, see if I can reproduce the bug.
>
> Adam,
>
> Could you also help to confirm that commit 7140aaf is OK and commit
> 8ae1266 is bad?

I mean to confirm "commit 7140aaf + git cherry-pick bd4aaf8" is OK
and commit 8ae1266 is bad.

Thanks.
--
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/

[toc] | [prev] | [next] | [standalone]

#1223412 — Re: 32-bit bio regression with 4.3 [was: Re: cgroup/loop Bad page state oops in Linux v4.2-rc3-136-g45b4b782e848]

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/

--
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/

[toc] | [prev] | [next] | [standalone]

#1225032 — Re: 32-bit bio regression with 4.3 [was: Re: cgroup/loop Bad page state oops in Linux v4.2-rc3-136-g45b4b782e848]

On Sat, Sep 12, 2015 at 9:19 AM, Ming Lei <ming.lei@canonical.com> wrote:
> 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?

Sorry for the delay in reply.  I'll try and work with Adam today to
get this tested.

josh
--
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/

[toc] | [prev] | [next] | [standalone]

#1226344 — Re: 32-bit bio regression with 4.3 [was: Re: cgroup/loop Bad page state oops in Linux v4.2-rc3-136-g45b4b782e848]

On Tue, Sep 15, 2015 at 8:14 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> On Sat, Sep 12, 2015 at 9:19 AM, Ming Lei <ming.lei@canonical.com> wrote:
>> 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?
>
> Sorry for the delay in reply.  I'll try and work with Adam today to
> get this tested.

FWIW, reproducing the environment to recreate this is rather difficult
at the moment for reasons unrelated to the kernel.  We're going to add
the patch to our rawhide kernel so it gets pulled into tomorrow's
compose.  We'll test it as soon as it is available and let you know.

josh
--
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/

[toc] | [prev] | [next] | [standalone]

#1227126 — Re: 32-bit bio regression with 4.3 [was: Re: cgroup/loop Bad page state oops in Linux v4.2-rc3-136-g45b4b782e848]

On Wed, 2015-09-16 at 13:56 -0400, Josh Boyer wrote:

> > > Josh, Adam, would you mind testing the above patch to see if it
> > > can fix
> > > your issue?
> > 
> > Sorry for the delay in reply.  I'll try and work with Adam today to
> > get this tested.
> 
> FWIW, reproducing the environment to recreate this is rather
> difficult
> at the moment for reasons unrelated to the kernel.  We're going to
> add
> the patch to our rawhide kernel so it gets pulled into tomorrow's
> compose.  We'll test it as soon as it is available and let you know.

The fix looks good in testing - today's 32-bit Rawhide installer
images boot successfully. Thanks.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


--
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/

[toc] | [prev] | [next] | [standalone]

#1227160 — Re: 32-bit bio regression with 4.3 [was: Re: cgroup/loop Bad page state oops in Linux v4.2-rc3-136-g45b4b782e848]

On Thu, Sep 17, 2015 at 11:24 PM, Adam Williamson <awilliam@redhat.com> wrote:
> On Wed, 2015-09-16 at 13:56 -0400, Josh Boyer wrote:
>
>> > > Josh, Adam, would you mind testing the above patch to see if it
>> > > can fix
>> > > your issue?
>> >
>> > Sorry for the delay in reply.  I'll try and work with Adam today to
>> > get this tested.
>>
>> FWIW, reproducing the environment to recreate this is rather
>> difficult
>> at the moment for reasons unrelated to the kernel.  We're going to
>> add
>> the patch to our rawhide kernel so it gets pulled into tomorrow's
>> compose.  We'll test it as soon as it is available and let you know.
>
> The fix looks good in testing - today's 32-bit Rawhide installer
> images boot successfully. Thanks.

That is great, and thanks for your test, and I'll prepare one formal version
for merge.

Thanks,
--
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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web