linux/block, branch v2.6.30

bsg: setting rq->bio to NULL

2009-06-09T13:17:37Z

Due to commit 1cd96c242a829d52f7a5ae98f554ca9775429685 ("block: WARN in __blk_put_request() for potential bio leak"), BSG SMP requests get the false warnings: WARNING: at block/blk-core.c:1068 __blk_put_request+0x52/0xc0() This sets rq->bio to NULL to avoid that false warnings. Signed-off-by: FUJITA Tomonori Signed-off-by: Jens Axboe

block: fix the bio_vec array index out-of-bounds test

2009-05-12T11:27:45Z

Current bio_vec array index out-of-bounds test within __end_that_request_first() does not seem correct. It checks bio->bi_idx against bio->bi_vcnt, but the subsequent code uses idx (which is, bio->bi_idx + next_idx) as the array index into bio_vec array. This means that the test really make sense only at the first iteration of !(nr_bytes >=bio->bi_size) case (when next_idx == zero). Fix this by replacing bio->bi_idx with idx. (This patch applies to 2.6.30-rc4.) Signed-off-by: Kazuhisa Ichikawa Signed-off-by: Jens Axboe

cfq-iosched: cache prio_tree root in cfqq->p_root

2009-04-24T06:54:22Z

Currently we look it up from ->ioprio, but ->ioprio can change if either the process gets its IO priority changed explicitly, or if cfq decides to temporarily boost it. So if we are unlucky, we can end up attempting to remove a node from a different rbtree root than where it was added. Fix this by using ->org_ioprio as the prio_tree index, since that will only change for explicit IO priority settings (not for a boost). Additionally cache the rbtree root inside the cfqq, then we don't have to add code to reinsert the cfqq in the prio_tree if IO priority changes. Signed-off-by: Jens Axboe

cfq-iosched: fix bug with aliased request and cooperation detection

2009-04-24T06:54:22Z

cfq_prio_tree_lookup() should return the direct match, yet it always returns zero. Fix that. cfq_prio_tree_add() assumes that we don't get a direct match, while it is very possible that we do. Using O_DIRECT, you can have different cfqq with matching requests, since you don't have the page cache to serialize things for you. Fix this bug by only adding the cfqq if there isn't an existing match. Signed-off-by: Jens Axboe

cfq-iosched: clear ->prio_trees[] on cfqd alloc

2009-04-24T06:54:22Z

Not strictly needed, but we should make it clear that we init the rbtree roots here. Signed-off-by: Jens Axboe

block: fix intermittent dm timeout based oops

2009-04-24T06:54:21Z

Very rarely under stress testing of dm, oopses are occuring as something tampers with an old stack frame. This has been traced back to blk_abort_queue() leaving a timeout_list pointing to the stack. The reason is that sometimes blk_abort_request() won't delete the timer (if the request is marked as complete but before the timer has been removed, a small race window). Fix this by splicing back from the ususally empty list to the q->timeout_list. Signed-off-by: Hannes Reinecke Signed-off-by: Jens Axboe

block: simplify I/O stat accounting

2009-04-24T06:54:21Z

This simplifies I/O stat accounting switching code and separates it completely from I/O scheduler switch code. Requests are accounted according to the state of their request queue at the time of the request allocation. There is no need anymore to flush the request queue when switching I/O accounting state. Signed-off-by: Jerome Marchand Signed-off-by: Jens Axboe

cfq-iosched: use the default seek distance when there aren't enough seek samples

2009-04-22T06:35:11Z

If the cfq io context doesn't have enough samples yet to provide a mean seek distance, then use the default threshold we have for seeky IO instead of defaulting to 0. Signed-off-by: Jeff Moyer Signed-off-by: Jens Axboe

cfq-iosched: make seek_mean converge more quickly

2009-04-22T06:35:11Z

Right now, depending on the first sector to which a process issues I/O, the seek time may start out way out of whack. So make sure we start with 0 sectors in seek, instead of the offset of the first request issued. Signed-off-by: Jeff Moyer Signed-off-by: Jens Axboe

block: make blk_abort_queue() ignore non-request based devices

2009-04-22T06:35:10Z

There's nothing to do for those devices, since the timeout handling is based on requests. Signed-off-by: Jens Axboe