Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp5485973imu; Tue, 13 Nov 2018 07:18:28 -0800 (PST) X-Google-Smtp-Source: AJdET5eGEaEu+DXvTsTwl6ZimSPmZtHBIN6EZEG+RALBQb2XVT+n2pZaDwS0jys4E61sFYs4UQtE X-Received: by 2002:a63:d34a:: with SMTP id u10mr5207551pgi.301.1542122308464; Tue, 13 Nov 2018 07:18:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542122308; cv=none; d=google.com; s=arc-20160816; b=rCS0Zifz9gP63NTjMzpuL+LHCNHupaqOrQoWBsxkayzBCfC+CTQENvXLfpFKqwq2ad tVuG1PCbS9rPhQDCqv9BThix2nI+BsT1w2kYW5i0qW9m5QqiLfqmO5SIyZp14y5JuQJ4 AlrTQnk3hQvjtMSYtj4jlRFdwliGJ9MFSkEjDThJExAoLy4v1WyPgEPAT6EMjifWhqbX RYdjzeKZz3o1JW6FKzHF+89jD8QrPj63Vfqxg4i5aFkwvpwoXAxKja5xj8OEUaKxiw5o H+XqTbAAqSOTmzHqxyEeOUFRW//SciJkksBVhENmguQ9d9nnE+yhkTv6aRaaIhdTHsV7 W8wQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=xJ4WKJmWfER1WxNAw76Ae37QdHvCd6OATv7zEDXA36k=; b=MM6rLiO+OlYtZRLCidLT/x/NAmmgaj5DL6SeemB3FUhWpkvoHpLadrMyzmmAt+5WXj na74qipqjMo/aatvZJZWZdMeCpFUQtAzVoci3fgbtsSHpN41qxb9p1vSm2X5bY1Y2uhC LNNwNZ+nxz4hieRkLgca9ISLFks4g1lWDZZR8qUk1Em2IplfcFAPVTznz2p+p7OBpI6T tPP39Id+Xwi5mwDLVRP5SD+WUVm8WPRcAPbY0lddPkeCWdc1N+xZwqDskp6/WgIxjD+R 0+2LuJy4CH05ngCXvK/eBJZieWepM+XCVznH2lM075/fdLk50ZveDC7FClBELhGybl4D 4Rcg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i13-v6si19994022pgo.128.2018.11.13.07.18.12; Tue, 13 Nov 2018 07:18:28 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388280AbeKNBPi (ORCPT + 99 others); Tue, 13 Nov 2018 20:15:38 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34786 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388268AbeKNBPh (ORCPT ); Tue, 13 Nov 2018 20:15:37 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2C34F308625C; Tue, 13 Nov 2018 15:17:03 +0000 (UTC) Received: from localhost (ovpn-8-23.pek2.redhat.com [10.72.8.23]) by smtp.corp.redhat.com (Postfix) with ESMTP id 649C81019635; Tue, 13 Nov 2018 15:16:49 +0000 (UTC) From: Ming Lei To: Jens Axboe Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, Ming Lei , Christoph Hellwig , Mike Snitzer , Kent Overstreet Subject: [PATCH V9 17/19] block: don't use bio->bi_vcnt to figure out segment number Date: Tue, 13 Nov 2018 23:15:03 +0800 Message-Id: <20181113151505.15498-18-ming.lei@redhat.com> In-Reply-To: <20181113151505.15498-1-ming.lei@redhat.com> References: <20181113151505.15498-1-ming.lei@redhat.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.49]); Tue, 13 Nov 2018 15:17:03 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org It is wrong to use bio->bi_vcnt to figure out how many segments there are in the bio even though CLONED flag isn't set on this bio, because this bio may be splitted or advanced. So always use bio_segments() in blk_recount_segments(), and it shouldn't cause any performance loss now because the physical segment number is figured out in blk_queue_split() and BIO_SEG_VALID is set meantime since bdced438acd83ad83a6c ("block: setup bi_phys_segments after splitting"). Fixes: 7f60dcaaf91 ("block: blk-merge: fix blk_recount_segments()") Cc: Christoph Hellwig Cc: Mike Snitzer Cc: Kent Overstreet Signed-off-by: Ming Lei --- block/blk-merge.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/block/blk-merge.c b/block/blk-merge.c index cb9f49bcfd36..153a659fde74 100644 --- a/block/blk-merge.c +++ b/block/blk-merge.c @@ -429,13 +429,7 @@ void blk_recalc_rq_segments(struct request *rq) void blk_recount_segments(struct request_queue *q, struct bio *bio) { - unsigned short seg_cnt; - - /* estimate segment number by bi_vcnt for non-cloned bio */ - if (bio_flagged(bio, BIO_CLONED)) - seg_cnt = bio_segments(bio); - else - seg_cnt = bio->bi_vcnt; + unsigned short seg_cnt = bio_segments(bio); if (test_bit(QUEUE_FLAG_NO_SG_MERGE, &q->queue_flags) && (seg_cnt < queue_max_segments(q))) -- 2.9.5