]> git.kernelconcepts.de Git - karo-tx-linux.git/commit
xen/blkfront: use blk_rq_map_sg to generate ring entries
authorJens Axboe <jens.axboe@oracle.com>
Tue, 24 Feb 2009 07:10:09 +0000 (08:10 +0100)
committerGreg Kroah-Hartman <gregkh@suse.de>
Tue, 17 Mar 2009 00:32:24 +0000 (17:32 -0700)
commitb42067185d9ea1dc6de51fa6245e1b4969b6cbad
tree981c6435c72df84fb7cc224bc7dc4bd13b507271
parent0109d01cfb91aa96c2d96da089945188d8c2d3d7
xen/blkfront: use blk_rq_map_sg to generate ring entries

commit 9e973e64ac6dc504e6447d52193d4fff1a670156 upstream.

On occasion, the request will apparently have more segments than we
fit into the ring. Jens says:

> The second problem is that the block layer then appears to create one
> too many segments, but from the dump it has rq->nr_phys_segments ==
> BLKIF_MAX_SEGMENTS_PER_REQUEST. I suspect the latter is due to
> xen-blkfront not handling the merging on its own. It should check that
> the new page doesn't form part of the previous page. The
> rq_for_each_segment() iterates all single bits in the request, not dma
> segments. The "easiest" way to do this is to call blk_rq_map_sg() and
> then iterate the mapped sg list. That will give you what you are
> looking for.

> Here's a test patch, compiles but otherwise untested. I spent more
> time figuring out how to enable XEN than to code it up, so YMMV!
> Probably the sg list wants to be put inside the ring and only
> initialized on allocation, then you can get rid of the sg on stack and
> sg_init_table() loop call in the function. I'll leave that, and the
> testing, to you.

[Moved sg array into info structure, and initialize once. -J]

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Sven Köhler <sven.koehler@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
drivers/block/xen-blkfront.c