* [PATCH] BUG: ll_merge_requests_fn() updates req->nr_phys_segments wrongly
@ 2008-09-23 18:28 Nikanth Karthikesan
2008-09-25 7:35 ` FUJITA Tomonori
2008-09-25 13:55 ` Jens Axboe
0 siblings, 2 replies; 3+ messages in thread
From: Nikanth Karthikesan @ 2008-09-23 18:28 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-kernel, linux-scsi, FUJITA Tomonori
From: Nikanth Karthikesan <knikanth@suse.de>
ll_merge_requests_fn() decreases the req->nr_phys_segments if
blk_phys_contig_segment() returns true, but it is perfectly possible that
blk_hw_contig_segment() is false. A new hw_segment implies a new phys_segment.
So decrementing nr_phys_segments wrongly here triggers the BUG_ON() in
scsi_init_sgtable(), as blk_rq_map_sg() would map 1 phys_segment more than
req->nr_phys_segment. This is easily reproducible. Other callers of
blk_rq_map_sg() should also be affected by this bug.
Signed-off-by: Nikanth Karthikesan <knikanth@suse.de>
---
block/blk-merge.c | 10 ++++------
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/block/blk-merge.c b/block/blk-merge.c
index 5efc9e7..6e6d04b 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -392,11 +392,6 @@ static int ll_merge_requests_fn(struct request_queue *q,
struct request *req,
return 0;
total_phys_segments = req->nr_phys_segments + next->nr_phys_segments;
- if (blk_phys_contig_segment(q, req->biotail, next->bio))
- total_phys_segments--;
-
- if (total_phys_segments > q->max_phys_segments)
- return 0;
total_hw_segments = req->nr_hw_segments + next->nr_hw_segments;
if (blk_hw_contig_segment(q, req->biotail, next->bio)) {
@@ -410,9 +405,12 @@ static int ll_merge_requests_fn(struct request_queue *q,
struct request *req,
if (next->nr_hw_segments == 1)
next->biotail->bi_hw_back_size = len;
total_hw_segments--;
+ if (blk_phys_contig_segment(q, req->biotail, next->bio))
+ total_phys_segments--;
}
- if (total_hw_segments > q->max_hw_segments)
+ if (total_phys_segments > q->max_phys_segments ||
+ total_hw_segments > q->max_hw_segments)
return 0;
/* Merge is OK... */
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [PATCH] BUG: ll_merge_requests_fn() updates req->nr_phys_segments wrongly
2008-09-23 18:28 [PATCH] BUG: ll_merge_requests_fn() updates req->nr_phys_segments wrongly Nikanth Karthikesan
@ 2008-09-25 7:35 ` FUJITA Tomonori
2008-09-25 13:55 ` Jens Axboe
1 sibling, 0 replies; 3+ messages in thread
From: FUJITA Tomonori @ 2008-09-25 7:35 UTC (permalink / raw)
To: knikanth; +Cc: jens.axboe, linux-kernel, linux-scsi, fujita.tomonori
On Tue, 23 Sep 2008 23:58:02 +0530
Nikanth Karthikesan <knikanth@suse.de> wrote:
>
> From: Nikanth Karthikesan <knikanth@suse.de>
>
> ll_merge_requests_fn() decreases the req->nr_phys_segments if
> blk_phys_contig_segment() returns true, but it is perfectly possible that
> blk_hw_contig_segment() is false.
Yeah, in fact, blk_hw_contig_segment() is always false on the majority
of architectures (on only PARISC and Alpha, it could be true).
Your patch doesn't look correct. Virtually, the patch always disables
physical merging.
> A new hw_segment implies a new phys_segment.
> So decrementing nr_phys_segments wrongly here triggers the BUG_ON() in
> scsi_init_sgtable(), as blk_rq_map_sg() would map 1 phys_segment more than
> req->nr_phys_segment. This is easily reproducible. Other callers of
> blk_rq_map_sg() should also be affected by this bug.
I have no idea how BUG_ON() in scsi_init_sgtable() is triggered.
Can you give more information, HBA, IOMMU (if you use), and the values
of req->nr_phys_segment, req->nr_hw_segment, count, etc in in
scsi_init_sgtable() when you hit the bug?
BTW, blk_hw_contig_segment() will be removed for 2.6.28 (virtual
merging account in the block layer will be removed).
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] BUG: ll_merge_requests_fn() updates req->nr_phys_segments wrongly
2008-09-23 18:28 [PATCH] BUG: ll_merge_requests_fn() updates req->nr_phys_segments wrongly Nikanth Karthikesan
2008-09-25 7:35 ` FUJITA Tomonori
@ 2008-09-25 13:55 ` Jens Axboe
1 sibling, 0 replies; 3+ messages in thread
From: Jens Axboe @ 2008-09-25 13:55 UTC (permalink / raw)
To: Nikanth Karthikesan; +Cc: linux-kernel, linux-scsi, FUJITA Tomonori
On Tue, Sep 23 2008, Nikanth Karthikesan wrote:
>
> From: Nikanth Karthikesan <knikanth@suse.de>
>
> ll_merge_requests_fn() decreases the req->nr_phys_segments if
> blk_phys_contig_segment() returns true, but it is perfectly possible that
> blk_hw_contig_segment() is false. A new hw_segment implies a new phys_segment.
> So decrementing nr_phys_segments wrongly here triggers the BUG_ON() in
> scsi_init_sgtable(), as blk_rq_map_sg() would map 1 phys_segment more than
> req->nr_phys_segment. This is easily reproducible. Other callers of
> blk_rq_map_sg() should also be affected by this bug.
>
> Signed-off-by: Nikanth Karthikesan <knikanth@suse.de>
> ---
>
> block/blk-merge.c | 10 ++++------
> 1 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/block/blk-merge.c b/block/blk-merge.c
> index 5efc9e7..6e6d04b 100644
> --- a/block/blk-merge.c
> +++ b/block/blk-merge.c
> @@ -392,11 +392,6 @@ static int ll_merge_requests_fn(struct request_queue *q,
> struct request *req,
> return 0;
>
> total_phys_segments = req->nr_phys_segments + next->nr_phys_segments;
> - if (blk_phys_contig_segment(q, req->biotail, next->bio))
> - total_phys_segments--;
This is totally broken, I gather you are thinking the bug is fixed since
the counts always match up. Well that's mainly because you know don't do
ANY merging.
> - if (total_phys_segments > q->max_phys_segments)
> - return 0;
Hmm?
I think you should try and describe the problem you are seeing instead,
then we can perhaps find the real issue.
--
Jens Axboe
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-09-25 13:55 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-09-23 18:28 [PATCH] BUG: ll_merge_requests_fn() updates req->nr_phys_segments wrongly Nikanth Karthikesan
2008-09-25 7:35 ` FUJITA Tomonori
2008-09-25 13:55 ` Jens Axboe
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox