search for: queue_max_segments

...according to several xfstests runs. Cheers, Dongsu ---- >From 1db98323931eb9ab430116c4d909d22222c16e22 Mon Sep 17 00:00:00 2001 From: Dongsu Park <dongsu.park at profitbricks.com> Date: Tue, 11 Nov 2014 13:10:59 +0100 Subject: [RFC PATCH] blk-merge: make bi_phys_segments consider also queue_max_segments() When recounting the number of physical segments, the number of max segments of request_queue must be also taken into account. Otherwise bio->bi_phys_segments could get bigger than queue_max_segments(). Then this results in virtio_queue_rq() seeing req->nr_phys_segments that is greater than...

...according to several xfstests runs. Cheers, Dongsu ---- >From 1db98323931eb9ab430116c4d909d22222c16e22 Mon Sep 17 00:00:00 2001 From: Dongsu Park <dongsu.park at profitbricks.com> Date: Tue, 11 Nov 2014 13:10:59 +0100 Subject: [RFC PATCH] blk-merge: make bi_phys_segments consider also queue_max_segments() When recounting the number of physical segments, the number of max segments of request_queue must be also taken into account. Otherwise bio->bi_phys_segments could get bigger than queue_max_segments(). Then this results in virtio_queue_rq() seeing req->nr_phys_segments that is greater than...

Hi, Mike Snitzer wrote: > This particular dm-crypt on virtio-blk issue is fixed with this commit: > http://git.kernel.org/linus/586b286b110e94eb31840ac5afc0c24e0881fe34 > > Linus pulled this into v4.3-rc3. I have this patch applied to linux-4.1.9. This could be the reason why I don't see the issue on boot with linux-4.1.9. So is the freeze I am experiencing with linux-4.1.9

Hi, seems like we have two problems: The first (origin) problem seems to be already fixed by Mike's patch. I applied the patch against linux-4.1.8, rebooted several times without a problem. But I'll keep testing for sure. The second problem is a new bug within linux-4.1.9: I experience the > NMI watchdog: BUG: soft lockup - CPU#3 stuck for 23s! freeze now on all my systems

Hi, Mike Snitzer wrote: > This particular dm-crypt on virtio-blk issue is fixed with this commit: > http://git.kernel.org/linus/586b286b110e94eb31840ac5afc0c24e0881fe34 > > Linus pulled this into v4.3-rc3. I have this patch applied to linux-4.1.9. This could be the reason why I don't see the issue on boot with linux-4.1.9. So is the freeze I am experiencing with linux-4.1.9

...2 2013 -0600 >> >> virtio_blk: blk-mq support >> >> >> BUG_ON(req->nr_phys_segments + 2 > vblk->sg_elems); >> >> >> On probe, we do >> /* We can handle whatever the host told us to handle. */ >> blk_queue_max_segments(q, vblk->sg_elems-2); >> >> >> To debug this, >> maybe you can print out sg_elems at init time and when this fails, >> to make sure some kind of memory corruption >> does not change sg_elems after initialization? >> >> >> Jens, how may we get...

...heers, > Dongsu > > ---- > > From 1db98323931eb9ab430116c4d909d22222c16e22 Mon Sep 17 00:00:00 2001 > From: Dongsu Park <dongsu.park at profitbricks.com> > Date: Tue, 11 Nov 2014 13:10:59 +0100 > Subject: [RFC PATCH] blk-merge: make bi_phys_segments consider also > queue_max_segments() > > When recounting the number of physical segments, the number of max > segments of request_queue must be also taken into account. > Otherwise bio->bi_phys_segments could get bigger than > queue_max_segments(). Then this results in virtio_queue_rq() seeing > req->nr_phys_...

...---- >> [ 64.670008] kernel BUG at drivers/block/virtio_blk.c:172! > > Hmm, that's: > > BUG_ON(req->nr_phys_segments + 2 > vblk->sg_elems); > > But during our probe routine we said: > > /* We can handle whatever the host told us to handle. */ > blk_queue_max_segments(q, vblk->sg_elems-2); > > Jens? Known, I'm afraid, Ming is looking into it. -- Jens Axboe

...---- >> [ 64.670008] kernel BUG at drivers/block/virtio_blk.c:172! > > Hmm, that's: > > BUG_ON(req->nr_phys_segments + 2 > vblk->sg_elems); > > But during our probe routine we said: > > /* We can handle whatever the host told us to handle. */ > blk_queue_max_segments(q, vblk->sg_elems-2); > > Jens? Known, I'm afraid, Ming is looking into it. -- Jens Axboe

...l.dk> > Date: Fri Nov 1 10:52:52 2013 -0600 > > virtio_blk: blk-mq support > > > BUG_ON(req->nr_phys_segments + 2 > vblk->sg_elems); > > > On probe, we do > /* We can handle whatever the host told us to handle. */ > blk_queue_max_segments(q, vblk->sg_elems-2); > > > To debug this, > maybe you can print out sg_elems at init time and when this fails, > to make sure some kind of memory corruption > does not change sg_elems after initialization? > > > Jens, how may we get more segments than blk_queue_ma...

...l.dk> > Date: Fri Nov 1 10:52:52 2013 -0600 > > virtio_blk: blk-mq support > > > BUG_ON(req->nr_phys_segments + 2 > vblk->sg_elems); > > > On probe, we do > /* We can handle whatever the host told us to handle. */ > blk_queue_max_segments(q, vblk->sg_elems-2); > > > To debug this, > maybe you can print out sg_elems at init time and when this fails, > to make sure some kind of memory corruption > does not change sg_elems after initialization? > > > Jens, how may we get more segments than blk_queue_ma...

...nel.dk> > Date: Fri Nov 1 10:52:52 2013 -0600 > > virtio_blk: blk-mq support > > > BUG_ON(req->nr_phys_segments + 2 > vblk->sg_elems); > > > On probe, we do > /* We can handle whatever the host told us to handle. */ > blk_queue_max_segments(q, vblk->sg_elems-2); > > > To debug this, > maybe you can print out sg_elems at init time and when this fails, > to make sure some kind of memory corruption > does not change sg_elems after initialization? > > > Jens, how may we get more segments than blk_queue_max_se...

...nel.dk> > Date: Fri Nov 1 10:52:52 2013 -0600 > > virtio_blk: blk-mq support > > > BUG_ON(req->nr_phys_segments + 2 > vblk->sg_elems); > > > On probe, we do > /* We can handle whatever the host told us to handle. */ > blk_queue_max_segments(q, vblk->sg_elems-2); > > > To debug this, > maybe you can print out sg_elems at init time and when this fails, > to make sure some kind of memory corruption > does not change sg_elems after initialization? > > > Jens, how may we get more segments than blk_queue_max_se...

...22b39e508375e7c1 Author: Jens Axboe <axboe at kernel.dk> Date: Fri Nov 1 10:52:52 2013 -0600 virtio_blk: blk-mq support BUG_ON(req->nr_phys_segments + 2 > vblk->sg_elems); On probe, we do /* We can handle whatever the host told us to handle. */ blk_queue_max_segments(q, vblk->sg_elems-2); To debug this, maybe you can print out sg_elems at init time and when this fails, to make sure some kind of memory corruption does not change sg_elems after initialization? Jens, how may we get more segments than blk_queue_max_segments? Is driver expected to validate an...

...ip_vcnt], page, len, offset); bip->bip_vcnt++; return len; diff --git a/block/bio.c b/block/bio.c index d7fbc7adfc50aa..71e411a0c12950 100644 --- a/block/bio.c +++ b/block/bio.c @@ -1029,10 +1029,7 @@ int bio_add_hw_page(struct request_queue *q, struct bio *bio, if (bio->bi_vcnt >= queue_max_segments(q)) return 0; - bvec = &bio->bi_io_vec[bio->bi_vcnt]; - bvec->bv_page = page; - bvec->bv_len = len; - bvec->bv_offset = offset; + bvec_set_page(&bio->bi_io_vec[bio->bi_vcnt], page, len, offset); bio->bi_vcnt++; bio->bi_iter.bi_size += len; return len; @...

...segs; } EXPORT_SYMBOL(blk_rq_map_sg); static inline int ll_new_hw_segment(struct request_queue *q, + struct blk_queue_ctx *ctx, struct request *req, struct bio *bio) { int nr_phys_segs = bio_phys_segments(q, bio); if (req->nr_phys_segments + nr_phys_segs > queue_max_segments(q)) goto no_merge; if (bio_integrity(bio) && blk_integrity_merge_bio(q, req, bio)) @@ -214,75 +217,77 @@ static inline int ll_new_hw_segment(struct request_queue *q, /* * This will form the start of a new hw segment. Bump both * counters. */ req->nr_phys_segments +=...

...segs; } EXPORT_SYMBOL(blk_rq_map_sg); static inline int ll_new_hw_segment(struct request_queue *q, + struct blk_queue_ctx *ctx, struct request *req, struct bio *bio) { int nr_phys_segs = bio_phys_segments(q, bio); if (req->nr_phys_segments + nr_phys_segs > queue_max_segments(q)) goto no_merge; if (bio_integrity(bio) && blk_integrity_merge_bio(q, req, bio)) @@ -214,75 +217,77 @@ static inline int ll_new_hw_segment(struct request_queue *q, /* * This will form the start of a new hw segment. Bump both * counters. */ req->nr_phys_segments +=...