From b31595992e52f94bd87c122dfad9cc37f15f82dc Mon Sep 17 00:00:00 2001 From: Ben Hutchings Date: Sun, 28 Nov 2010 23:46:46 +0000 Subject: [PATCH] dm: Deal with merge_bvec_fn in component devices better This is analogous to commit 627a2d3c29427637f4c5d31ccc7fcbd8d312cd71, which does the same for md-devices at the top of the stack. The following explanation is taken from that commit. Thanks to Neil Brown for the advice. If a component device has a merge_bvec_fn then as we never call it we must ensure we never need to. Currently this is done by setting max_sector to 1 PAGE, however this does not stop a bio being created with several sub-page iovecs that would violate the merge_bvec_fn. So instead set max_segments to 1 and set the segment boundary to the same as a page boundary to ensure there is only ever one single-page segment of IO requested at a time. This can particularly be an issue when 'xen' is used as it is known to submit multiple small buffers in a single bio. Signed-off-by: Ben Hutchings --- drivers/md/dm-table.c | 14 +++++++------- 1 files changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c index 90267f8..776734d 100644 --- a/drivers/md/dm-table.c +++ b/drivers/md/dm-table.c @@ -511,15 +511,15 @@ int dm_set_device_limits(struct dm_target *ti, struct dm_dev *dev, (unsigned long long) start << SECTOR_SHIFT); /* - * Check if merge fn is supported. - * If not we'll force DM to use PAGE_SIZE or - * smaller I/O, just to be safe. + * If we don't call merge_bvec_fn, we must never risk + * violating it, so limit max_phys_segments to 1 lying within + * a single page. */ + if (q->merge_bvec_fn && !ti->type->merge) { + limits->max_segments = 1; + limits->seg_boundary_mask = PAGE_CACHE_SIZE - 1; + } - if (q->merge_bvec_fn && !ti->type->merge) - limits->max_sectors = - min_not_zero(limits->max_sectors, - (unsigned int) (PAGE_SIZE >> 9)); return 0; } EXPORT_SYMBOL_GPL(dm_set_device_limits); -- 1.7.2.3