From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751157Ab0CHFeJ (ORCPT ); Mon, 8 Mar 2010 00:34:09 -0500 Received: from cantor2.suse.de ([195.135.220.15]:46258 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750950Ab0CHFd7 (ORCPT ); Mon, 8 Mar 2010 00:33:59 -0500 Date: Mon, 8 Mar 2010 16:33:45 +1100 From: Neil Brown To: Lars Ellenberg Cc: Alasdair G Kergon , device-mapper development , Mikulas Patocka , jens.axboe@oracle.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] dm: max_segments=1 if merge_bvec_fn is not supported Message-ID: <20100308163345.42841480@notabene.brown> In-Reply-To: <20100306211012.GA9689@racke> References: <20100306211012.GA9689@racke> X-Mailer: Claws Mail 3.7.4 (GTK+ 2.18.6; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 6 Mar 2010 22:10:13 +0100 Lars Ellenberg wrote: > If the lower device exposes a merge_bvec_fn, > dm_set_device_limits() restricts max_sectors > to PAGE_SIZE "just to be safe". > > This is not sufficient, however. > > If someone uses bio_add_page() to add 8 disjunct 512 byte partial > pages to a bio, it would succeed, but could still cross a border > of whatever restrictions are below us (e.g. raid10 stripe boundary). > An attempted bio_split() would not succeed, because bi_vcnt is 8. > > One example that triggered this frequently is the xen io layer. > > raid10_make_request bug: can't convert block across chunks or bigger than 64k 209265151 1 > > Signed-off-by: Lars > > --- > > Neil: you may want to double check linear.c and raid*.c for similar logic, > even though it is unlikely that someone puts md raid6 on top of something > exposing a merge_bvec_fn. > Unlikely, but by no means impossible. I have queued up an appropriate fix for md. Thanks! NeilBrown > This is not the first time this has been patched, btw. > See https://bugzilla.redhat.com/show_bug.cgi?id=440093 > and the patch by Mikulas: > https://bugzilla.redhat.com/attachment.cgi?id=342638&action=diff > > --- > drivers/md/dm-table.c | 12 ++++++++++-- > 1 files changed, 10 insertions(+), 2 deletions(-) > > diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c > index 4b22feb..c686ff4 100644 > --- a/drivers/md/dm-table.c > +++ b/drivers/md/dm-table.c > @@ -515,14 +515,22 @@ int dm_set_device_limits(struct dm_target *ti, struct dm_dev *dev, > > /* > * Check if merge fn is supported. > - * If not we'll force DM to use PAGE_SIZE or > + * If not we'll force DM to use single bio_vec of PAGE_SIZE or > * smaller I/O, just to be safe. > */ > > - if (q->merge_bvec_fn && !ti->type->merge) > + if (q->merge_bvec_fn && !ti->type->merge) { > limits->max_sectors = > min_not_zero(limits->max_sectors, > (unsigned int) (PAGE_SIZE >> 9)); > + /* Restricting max_sectors is not enough. > + * If someone uses bio_add_page to add 8 disjunct 512 byte > + * partial pages to a bio, it would succeed, > + * but could still cross a border of whatever restrictions > + * are below us (e.g. raid0 stripe boundary). An attempted > + * bio_split() would not succeed, because bi_vcnt is 8. */ > + limits->max_segments = 1; > + } > return 0; > } > EXPORT_SYMBOL_GPL(dm_set_device_limits);