From patchwork Thu Apr 14 12:02:19 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ming Lei X-Patchwork-Id: 8835341 Return-Path: X-Original-To: patchwork-linux-block@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 63698C0553 for ; Thu, 14 Apr 2016 12:12:53 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 7858620173 for ; Thu, 14 Apr 2016 12:12:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9BD0120122 for ; Thu, 14 Apr 2016 12:12:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754542AbcDNMDP (ORCPT ); Thu, 14 Apr 2016 08:03:15 -0400 Received: from mail-oi0-f68.google.com ([209.85.218.68]:34049 "EHLO mail-oi0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754475AbcDNMDN (ORCPT ); Thu, 14 Apr 2016 08:03:13 -0400 Received: by mail-oi0-f68.google.com with SMTP id q133so9553523oib.1; Thu, 14 Apr 2016 05:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=krJV4gRN6TVSHxqKpvZECroY4dOx8tXR5Nn1ntYFDOo=; b=O5yK1eWc8GHJeKelpDWkvE4Bh1TmcFv7CIcmfwH57V4NIokODMxpe4BMtuZnNm5srW S1Z2rucDRtNLR3yjMD8vDz2IvTTRxm3bLZL2QKNq0QvdWmzhMZl4g0aBis2+cHIdmQ0v YtfYSIrhicxVG8WetC5TB1vBtAtHCaWctIuuFhVJUEj6GpNIEgum7NMUusSM+B7cS9PX p3XSwmB+QBTar71dmd3Xlg/tguLXlvot5Qsdlho4xKgFawKTGYzvSqgAfd8e2ixYFf83 64xd8Es2hjIHgy+XY31rGnKV9MxEYQmx2eVw9/M//+FZifk6a1U/6zVVGG44pt+rMo9O SgQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=krJV4gRN6TVSHxqKpvZECroY4dOx8tXR5Nn1ntYFDOo=; b=cRBIKIUpUjt0wXA+/S8CYBPa7mS+y8Oa7FV9iwA+hXu5Fn3LKnG8kPJ9GIo2YLEvOV LAOb0UJJpsiF9cWo5BB26uFU+jmOJCj8NKOWFYZRLbMpPe7KZlUabPUcDQjivNMbTXAQ zims2vYx/84IUnZOEbXg0LcECxq8kECntSKz73cIUYjz13gMEFFrjWl9zxcNRgXDd7BC vrb8K3rgcIoYzUv8tARkREZb2SN2kL62qdadBQzYpcK1wZaGllGJZk0zdrPdc5EuwCf1 8PjaGwaICe1wOG0dE1qN9wfvA4TXTr9HBDWTVOahytDzUsWBwIDoMVvsDCzZeoXtI2oJ N+Tw== X-Gm-Message-State: AOPr4FVe5I+8E8/f8cldRYZnjlOIsPcyULx8OlN8hH+uorYGbXPSQx2oG8bZmBkupBbbbA== X-Received: by 10.202.208.131 with SMTP id h125mr7361398oig.87.1460635392888; Thu, 14 Apr 2016 05:03:12 -0700 (PDT) Received: from localhost ([12.228.154.70]) by smtp.gmail.com with ESMTPSA id m2sm13195219oia.1.2016.04.14.05.03.12 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Thu, 14 Apr 2016 05:03:12 -0700 (PDT) From: Ming Lei To: Jens Axboe , linux-kernel@vger.kernel.org Cc: linux-block@vger.kernel.org, Christoph Hellwig , Ming Lei , Jan Kara , Keith Busch , Kent Overstreet , "Kirill A. Shutemov" , Mike Snitzer Subject: [PATCH v1 01/27] block: bio: introduce 3 helpers for cleanup Date: Thu, 14 Apr 2016 20:02:19 +0800 Message-Id: <1460635375-28282-2-git-send-email-tom.leiming@gmail.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1460635375-28282-1-git-send-email-tom.leiming@gmail.com> References: <1460635375-28282-1-git-send-email-tom.leiming@gmail.com> Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham 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 Some drivers access bio->bi_vcnt and bio->bi_io_vec directly. Firstly it isn't a good practice. Secondly it may cause trouble for converting to multipage bvecs because currently drivers may suppose one bvec always include one page, and use the two fields to figure out how to handle pages. So this patches introduces 3 helpers for cleaning up this kind of usage. bio_pages() can be convertd to support multipage bvecs easily. For bio_get_base_vec() and bio_set_vec_table(), they are often used during initializing a new bio or in case of single bvec bio. With the two new helpers, it becomes easy to audit access of .bi_io_vec and .bi_vcnt and check if this kind of use is good for supporting multipage bvecs. Signed-off-by: Ming Lei --- include/linux/bio.h | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/include/linux/bio.h b/include/linux/bio.h index 6b7481f..2229006d 100644 --- a/include/linux/bio.h +++ b/include/linux/bio.h @@ -310,6 +310,27 @@ static inline void bio_clear_flag(struct bio *bio, unsigned int bit) bio->bi_flags &= ~(1U << bit); } +static inline struct bio_vec *bio_get_base_vec(struct bio *bio) +{ + return __bvec_iter_bvec(bio->bi_io_vec, bio->bi_iter); +} + +/* This helper should be used for setting bvec table on a new bio */ +static inline void bio_set_vec_table(struct bio *bio, struct bio_vec *table, + unsigned max_vecs) +{ + bio->bi_io_vec = table; + bio->bi_max_vecs = max_vecs; +} + +/* For singlepage bvecs, one segment includes one page */ +static inline unsigned bio_pages(struct bio *bio) +{ + if (!bio_flagged(bio, BIO_CLONED)) + return bio->bi_vcnt; + return bio_segments(bio); +} + static inline void bio_get_first_bvec(struct bio *bio, struct bio_vec *bv) { *bv = bio_iovec(bio);