From patchwork Sun Sep 1 16:01:46 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ben Hutchings X-Patchwork-Id: 2852583 X-Patchwork-Delegate: snitzer@redhat.com Return-Path: X-Original-To: patchwork-dm-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 5F5979F313 for ; Sun, 1 Sep 2013 16:11:41 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 8BC5D202C0 for ; Sun, 1 Sep 2013 16:11:40 +0000 (UTC) Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by mail.kernel.org (Postfix) with ESMTP id 83D91202C6 for ; Sun, 1 Sep 2013 16:11:39 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r81G20mm031721; Sun, 1 Sep 2013 12:02:02 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r81G1wZI028494 for ; Sun, 1 Sep 2013 12:01:58 -0400 Received: from mx1.redhat.com (ext-mx12.extmail.prod.ext.phx2.redhat.com [10.5.110.17]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r81G1wc9003232; Sun, 1 Sep 2013 12:01:58 -0400 Received: from shadbolt.e.decadent.org.uk (shadbolt.e.decadent.org.uk [88.96.1.126]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r81G1tPx004298; Sun, 1 Sep 2013 12:01:56 -0400 Received: from deadeye.wl.decadent.org.uk ([192.168.4.101]) by shadbolt.decadent.org.uk with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1VGA64-0000Yg-9A; Sun, 01 Sep 2013 17:01:52 +0100 Received: from ben by deadeye.wl.decadent.org.uk with local (Exim 4.80) (envelope-from ) id 1VGA63-0008U4-Ln; Sun, 01 Sep 2013 17:01:51 +0100 Message-ID: <1378051306.25743.18.camel@deadeye.wl.decadent.org.uk> From: Ben Hutchings To: Alasdair Kergon , Mike Snitzer Date: Sun, 01 Sep 2013 17:01:46 +0100 Mime-Version: 1.0 X-SA-Exim-Connect-IP: 192.168.4.101 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false X-RedHat-Spam-Score: -5.023 (BAYES_00, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD, URIBL_BLOCKED) X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-Scanned-By: MIMEDefang 2.68 on 10.5.110.17 X-loop: dm-devel@redhat.com Cc: 604457@bugs.debian.org, dm-devel@redhat.com Subject: [dm-devel] [PATCH] dm: Deal with merge_bvec_fn in component devices better X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk Reply-To: device-mapper development List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com X-Spam-Status: No, score=-9.3 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP This is analogous to commit 627a2d3c29427637f4c5d31ccc7fcbd8d312cd71 ('md: deal with merge_bvec_fn in component devices better.'), 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. References: http://bugs.debian.org/604457 Signed-off-by: Ben Hutchings --- We've been carrying this in Debian for about 3 years and it's about time it got reviewed... It's basically Neil's work so should probably have his sign-off as well. Ben. --- a/drivers/md/dm-table.c +++ b/drivers/md/dm-table.c @@ -536,13 +536,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 (dm_queue_merge_is_compulsory(q) && !ti->type->merge) - blk_limits_max_hw_sectors(limits, - (unsigned int) (PAGE_SIZE >> 9)); + if (dm_queue_merge_is_compulsory(q) && !ti->type->merge) { + limits->max_segments = 1; + limits->seg_boundary_mask = PAGE_CACHE_SIZE - 1; + } + return 0; } EXPORT_SYMBOL_GPL(dm_set_device_limits);