Re: [PATCH] bio: decrease bi_iter.bi_size by len in the fail path

[Jet Chen]

On 05/29/2014 12:13 PM, Ming Lei wrote:
> On Thu, May 29, 2014 at 11:35 AM, Jet Chen <jet.chen@xxxxxxxxx> wrote:
> > On 05/29/2014 12:59 AM, Ming Lei wrote:
> > > On Wed, May 28, 2014 at 11:42 PM, Ming Lei <tom.leiming@xxxxxxxxx> wrote:
> > > > Hi Dongsu,
> > > >
> > > > On Wed, May 28, 2014 at 11:09 PM, Dongsu Park
> > > > <dongsu.park@xxxxxxxxxxxxxxxx> wrote:
> > > > > From: Dongsu Park <dongsu.park@xxxxxxxxxxxxxxxx>
> > > > >
> > > > > Commit 3979ef4dcf3d1de55a560a3a4016c30a835df44d ("bio-modify-
> > > > > __bio_add_page-to-accept-pages-that-dont-start-a-new-segment-v3")
> > > > > introduced a regression as reported by Jet Chen.
> > > > > That results in a kernel BUG at drivers/block/virtio_blk.c:166.
> > > > >
> > > > > To fix that, bi_iter.bi_size must be decreased by len, before
> > > > > recounting the number of physical segments.
> > > > >
> > > > > Tested on with kernel 3.15.0-rc7-next-20140527 on qemu guest,
> > > > > by running xfstests/ext4/271.
> > > > >
> > > > > Cc: Jens Axboe <axboe@xxxxxxxxx>
> > > > > Cc: Jet Chen <jet.chen@xxxxxxxxx>
> > > > > Cc: Maurizio Lombardi <mlombard@xxxxxxxxxx>
> > > > > Signed-off-by: Dongsu Park <dongsu.park@xxxxxxxxxxxxxxxx>
> > > > > ---
> > > > >   block/bio.c | 1 +
> > > > >   1 file changed, 1 insertion(+)
> > > > >
> > > > > diff --git a/block/bio.c b/block/bio.c
> > > > > index 0443694ccbb4..67d7cba1e5fd 100644
> > > > > --- a/block/bio.c
> > > > > +++ b/block/bio.c
> > > > > @@ -810,6 +810,7 @@ static int __bio_add_page(struct request_queue *q, struct bio *bio, struct page
> > > > >          bvec->bv_len = 0;
> > > > >          bvec->bv_offset = 0;
> > > > >          bio->bi_vcnt--;
> > > > > +       bio->bi_iter.bi_size -= len;
> > > >
> > > > Would you mind explaining why bi_iter.bi_size need to be
> > > > decreased by 'len'? In the failure path, it wasn't added by
> > > > 'len', was it?
> > >
> > > Actually, the correct thing may be like what did in the
> > > attached patch, as Maurizio discussed with me[1].
> > >
> > > Very interestingly, I have reproduced the problem one time
> > > with ext4/271 ext4/301 ext4/305, but won't with the attached
> > > patch after running it for 3 rounds.
> > >
> > > [tom@localhost xfstests]$ sudo ./check ext4/271 ext4/301 ext4/305
> > > FSTYP         -- ext4
> > > PLATFORM      -- Linux/x86_64 localhost 3.15.0-rc7-next-20140527+
> > > MKFS_OPTIONS  -- /dev/vdc
> > > MOUNT_OPTIONS -- -o acl,user_xattr /dev/vdc /mnt/scratch
> > >
> > > ext4/271 1s ... 1s
> > > ext4/301 31s ... 32s
> > > ext4/305 181s ... 180s
> > > Ran: ext4/271 ext4/301 ext4/305
> > > Passed all 3 tests
> > >
> > > Jet, could you test the attached patch?
> >
> > sorry, could you specify which patch need me to test ?
> > actually I got confused. I only find
>
> Firstly, dongsu's patch is wrong, and it doesn't make sense to test
> that.
>
> Secondly, it is the patch attached in my last email, and the
> name is 'fix_compute_segments.patch'.
>
> Please let me know if you can find the patch, if you still can't, I
> may resend to you.

Just got your email which attached that patch, thanks. I guess there is some network problem on my side which leads to some latency.
Will test it out.

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