From patchwork Mon Jun 26 12:09:55 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ming Lei X-Patchwork-Id: 9809507 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 2A6FD603F3 for ; Mon, 26 Jun 2017 12:29:01 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3135D274D1 for ; Mon, 26 Jun 2017 12:29:01 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 257F828585; Mon, 26 Jun 2017 12:29:01 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D75232857B for ; Mon, 26 Jun 2017 12:29:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752466AbdFZMPC (ORCPT ); Mon, 26 Jun 2017 08:15:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41696 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751965AbdFZMOz (ORCPT ); Mon, 26 Jun 2017 08:14:55 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 343C580F63; Mon, 26 Jun 2017 12:14:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 343C580F63 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=ming.lei@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 343C580F63 Received: from localhost (ovpn-12-86.pek2.redhat.com [10.72.12.86]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1C3BD7ADA9; Mon, 26 Jun 2017 12:14:36 +0000 (UTC) From: Ming Lei To: Jens Axboe , Christoph Hellwig , Huang Ying , Andrew Morton , Alexander Viro Cc: linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Ming Lei , Shaohua Li , linux-raid@vger.kernel.org Subject: [PATCH v2 12/51] md: raid10: avoid to access bvec table directly Date: Mon, 26 Jun 2017 20:09:55 +0800 Message-Id: <20170626121034.3051-13-ming.lei@redhat.com> In-Reply-To: <20170626121034.3051-1-ming.lei@redhat.com> References: <20170626121034.3051-1-ming.lei@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 26 Jun 2017 12:14:44 +0000 (UTC) Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Inside sync_request_write(), .bi_vcnt is written after this bio is reseted, this way won't work any more after multipage bvec is enabled. So reset_bvec_table() is introduced for re-add these pages into bio, then .bi_vcnt needn't to be touched any more. Cc: Shaohua Li Cc: linux-raid@vger.kernel.org Signed-off-by: Ming Lei --- drivers/md/raid10.c | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c index 5026e7ad51d3..2fca1fe67092 100644 --- a/drivers/md/raid10.c +++ b/drivers/md/raid10.c @@ -1995,6 +1995,24 @@ static void end_sync_write(struct bio *bio) end_sync_request(r10_bio); } +/* called after bio_reset() */ +static void reset_bvec_table(struct bio *bio, struct resync_pages *rp, int size) +{ + /* initialize bvec table again */ + rp->idx = 0; + do { + struct page *page = resync_fetch_page(rp, rp->idx++); + int len = min_t(int, size, PAGE_SIZE); + + /* + * won't fail because the vec table is big + * enough to hold all these pages + */ + bio_add_page(bio, page, len, 0); + size -= len; + } while (rp->idx < RESYNC_PAGES && size > 0); +} + /* * Note: sync and recover and handled very differently for raid10 * This code is for resync. @@ -2087,8 +2105,8 @@ static void sync_request_write(struct mddev *mddev, struct r10bio *r10_bio) rp = get_resync_pages(tbio); bio_reset(tbio); - tbio->bi_vcnt = vcnt; - tbio->bi_iter.bi_size = fbio->bi_iter.bi_size; + reset_bvec_table(tbio, rp, fbio->bi_iter.bi_size); + rp->raid_bio = r10_bio; tbio->bi_private = rp; tbio->bi_iter.bi_sector = r10_bio->devs[i].addr;