summaryrefslogtreecommitdiffstats
path: root/samples
diff options
context:
space:
mode:
authorFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>2008-10-13 14:19:05 +0200
committerJens Axboe <jens.axboe@oracle.com>2008-10-17 08:46:56 +0200
commit8677142710516d986d932d6f1fba7be8382c1fec (patch)
tree5221f48b4e7e62590f8bbb832b4065886681d6cf /samples
parent0fc71e3d6520ba7abad5cfbc9a33db0190e4d5b8 (diff)
downloadlinux-8677142710516d986d932d6f1fba7be8382c1fec.tar.bz2
block: fix nr_phys_segments miscalculation bug
This fixes the bug reported by Nikanth Karthikesan <knikanth@suse.de>: http://lkml.org/lkml/2008/10/2/203 The root cause of the bug is that blk_phys_contig_segment miscalculates q->max_segment_size. blk_phys_contig_segment checks: req->biotail->bi_size + next_req->bio->bi_size > q->max_segment_size But blk_recalc_rq_segments might expect that req->biotail and the previous bio in the req are supposed be merged into one segment. blk_recalc_rq_segments might also expect that next_req->bio and the next bio in the next_req are supposed be merged into one segment. In such case, we merge two requests that can't be merged here. Later, blk_rq_map_sg gives more segments than it should. We need to keep track of segment size in blk_recalc_rq_segments and use it to see if two requests can be merged. This patch implements it in the similar way that we used to do for hw merging (virtual merging). Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Diffstat (limited to 'samples')
0 files changed, 0 insertions, 0 deletions