From patchwork Wed Jun 27 20:09:05 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bart Van Assche X-Patchwork-Id: 10492585 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 55DE1601A0 for ; Wed, 27 Jun 2018 20:09:07 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6028F29FC2 for ; Wed, 27 Jun 2018 20:09:07 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5440329FF3; Wed, 27 Jun 2018 20:09:07 +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=-7.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=ham 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 D0FE129FC2 for ; Wed, 27 Jun 2018 20:09:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966516AbeF0UJG (ORCPT ); Wed, 27 Jun 2018 16:09:06 -0400 Received: from esa6.hgst.iphmx.com ([216.71.154.45]:6532 "EHLO esa6.hgst.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966499AbeF0UJF (ORCPT ); Wed, 27 Jun 2018 16:09:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wdc.com; i=@wdc.com; q=dns/txt; s=dkim.wdc.com; t=1530130146; x=1561666146; h=from:to:cc:subject:date:message-id; bh=0b6X4WIcq69oQIt61WL07SZbqhJVX+roj2Kcoq1T+6Y=; b=JjyGhY8aWgOfB8FrEiyvOlAufbIBZP7U221VKBswQZuJVCCEa+FKByBz f8QOmMEFFzkJmO49gGOLXOlbKbGG/Oj7z17Kbkx/XAnsnmOJyKuBMvN3q 9KgE3qLTC/1YhAq9cA18Yu13VVc8jnA6zEwNpPJbuwtd7gh3MzDsL5dT2 nhwcBy8zA3T/iKDJykKRpeM72P5kKciZnFjfPFgKOOhR1vfjmRKGXo+O4 tKy3Zsetc8y3+DiMPTo7L3c2XVavPg3xtUD6gScV1KfUKcA6qiicxxM+m JaQMObQxA0R7TPoFnHcmHY/8RewdGC1NZSrRpCzz0yjfg8XTgP3IJhkZG g==; X-IronPort-AV: E=Sophos;i="5.51,280,1526313600"; d="scan'208";a="83340861" Received: from uls-op-cesaip02.wdc.com (HELO uls-op-cesaep02.wdc.com) ([199.255.45.15]) by ob1.hgst.iphmx.com with ESMTP; 28 Jun 2018 04:09:06 +0800 Received: from uls-op-cesaip02.wdc.com ([10.248.3.37]) by uls-op-cesaep02.wdc.com with ESMTP; 27 Jun 2018 12:58:22 -0700 Received: from thinkpad-bart.sdcorp.global.sandisk.com ([10.111.67.248]) by uls-op-cesaip02.wdc.com with ESMTP; 27 Jun 2018 13:09:06 -0700 From: Bart Van Assche To: Jens Axboe Cc: linux-block@vger.kernel.org, Christoph Hellwig , Bart Van Assche , Ming Lei Subject: [PATCH] block: Document how blk_update_request() handles RQF_SPECIAL_PAYLOAD requests Date: Wed, 27 Jun 2018 13:09:05 -0700 Message-Id: <20180627200905.15226-1-bart.vanassche@wdc.com> X-Mailer: git-send-email 2.17.1 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 The payload of struct request is stored in the request.bio chain if the RQF_SPECIAL_PAYLOAD flag is not set and in request.special_vec if RQF_SPECIAL_PAYLOAD has been set. However, blk_update_request() iterates over req->bio whether or not RQF_SPECIAL_PAYLOAD has been set. Additionally, the RQF_SPECIAL_PAYLOAD flag is ignored by blk_rq_bytes() which means that the value returned by that function is incorrect if the RQF_SPECIAL_PAYLOAD flag has been set. It is not clear to me whether this is an oversight or whether this happened on purpose. Anyway, document that it is known that both functions ignore RQF_SPECIAL_PAYLOAD. See also commit f9d03f96b988 ("block: improve handling of the magic discard payload"). Signed-off-by: Bart Van Assche Cc: Christoph Hellwig Cc: Ming Lei Reviewed-by: Christoph Hellwig --- block/blk-core.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/block/blk-core.c b/block/blk-core.c index 5ac03e3ab786..f1e07ed1513c 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -3098,6 +3098,10 @@ EXPORT_SYMBOL_GPL(blk_steal_bios); * Passing the result of blk_rq_bytes() as @nr_bytes guarantees * %false return from this function. * + * Note: + * The RQF_SPECIAL_PAYLOAD flag is ignored on purpose in both + * blk_rq_bytes() and in blk_update_request(). + * * Return: * %false - this request doesn't have any more data * %true - this request has more data