From patchwork Wed Feb 8 21:59:46 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chuck Lever X-Patchwork-Id: 9564143 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 9E07760216 for ; Thu, 9 Feb 2017 07:30:20 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5E673284FA for ; Thu, 9 Feb 2017 07:30:20 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 52FB82850D; Thu, 9 Feb 2017 07:30:20 +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=-4.7 required=2.0 tests=BAYES_00, DATE_IN_PAST_06_12, DKIM_SIGNED,RCVD_IN_DNSWL_HI,RCVD_IN_SORBS_SPAM,T_DKIM_INVALID 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 BE5BB284FA for ; Thu, 9 Feb 2017 07:30:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751615AbdBIHaQ (ORCPT ); Thu, 9 Feb 2017 02:30:16 -0500 Received: from mail-it0-f65.google.com ([209.85.214.65]:33613 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751499AbdBIHaP (ORCPT ); Thu, 9 Feb 2017 02:30:15 -0500 Received: by mail-it0-f65.google.com with SMTP id e137so1490225itc.0 for ; Wed, 08 Feb 2017 23:28:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:from:to:cc:date:message-id:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=zViyIuWZP8cQHztQyn2/RPfWKblZf8sNS3XgHHFYooA=; b=kI5yguHwJRkxB4SSqhHoP92Jm0gnQNSxxLzCQgdXE+YXBR7+FhzofyAynQL6lb8ylC agTsI2MjW+AS34aWzgPR8FqiTsD7u/grABrorrkmAi3CiSodzCqOqjCp3H7uZc8Khszp YvclwgBZa0qbgrBKWcJbGdAtxN+rHpz1UheVm0Dmv7akKTHM6J4BO8wjtTOBiQhiU//e KJxQz23mCxlTA8lRzLd4svTOxPEyN2CGqIDXQjJppwTRMASudbDGaz5HYoLlhLaVQ07a qYrZ4jU2TAEVVbSjor1c3kNYnBmE7KvkcNr0jWMM8hjsgT5aP56WrkLkON00Zu2s8vjA BblQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:from:to:cc:date:message-id :in-reply-to:references:user-agent:mime-version :content-transfer-encoding; bh=zViyIuWZP8cQHztQyn2/RPfWKblZf8sNS3XgHHFYooA=; b=YgRGiYF/dNOW4ou5f1gmuxwsI+4BFPS8iJHPHQLjd1TEGxznIG7u0ySRo5toQOUH9f lsg0w+j4SK1akyYmwPcLuO3JvN5MZW+idogFuT5/chVMw4FVvL3BBqGpBJBqBM0v+3a5 luuFNUzWyRnap9awK3M3zgW4lYa1Kuxz5xdiD3ENAuk7zGy23lZtiOOip/S298LC34ie 8+SYazUUom7CwJ7QISzc8sANn7LdmqYQjcEbsM4s2KqpxozpAwXPo6TPtrLZfn/n876K RxXZpzDG2hLcyFsAsD5ud5bSpUQ2YQ1nzZt9wjg9tH/n2YeAsJj1AN3TH5A7VhcVa78J FrLA== X-Gm-Message-State: AIkVDXIhVqfiMOQln/oIkfaVAqmzC3PzHnuVX770q13C72kpNtEPvwwJ0P+eusWNp1Fctw== X-Received: by 10.36.95.134 with SMTP id r128mr18667895itb.15.1486591187296; Wed, 08 Feb 2017 13:59:47 -0800 (PST) Received: from manet.1015granger.net ([2604:8800:100:81fc:ec4:7aff:fe6c:1dce]) by smtp.gmail.com with ESMTPSA id 9sm1741409itm.18.2017.02.08.13.59.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Feb 2017 13:59:46 -0800 (PST) Subject: [PATCH v3 01/12] xprtrdma: Fix Read chunk padding From: Chuck Lever To: anna.schumaker@netapp.com Cc: linux-rdma@vger.kernel.org, linux-nfs@vger.kernel.org Date: Wed, 08 Feb 2017 16:59:46 -0500 Message-ID: <20170208215946.7152.65727.stgit@manet.1015granger.net> In-Reply-To: <20170208214854.7152.83331.stgit@manet.1015granger.net> References: <20170208214854.7152.83331.stgit@manet.1015granger.net> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP When pad optimization is disabled, rpcrdma_convert_iovs still does not add explicit XDR round-up padding to a Read chunk. Commit 677eb17e94ed ("xprtrdma: Fix XDR tail buffer marshalling") incorrectly short-circuited the test for whether round-up padding is needed that appears later in rpcrdma_convert_iovs. However, if this is indeed a regular Read chunk (and not a Position-Zero Read chunk), the tail iovec _always_ contains the chunk's padding, and never anything else. So, it's easy to just skip the tail when padding optimization is enabled, and add the tail in a subsequent Read chunk segment, if disabled. Fixes: 677eb17e94ed ("xprtrdma: Fix XDR tail buffer marshalling") Signed-off-by: Chuck Lever --- net/sunrpc/xprtrdma/rpc_rdma.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/net/sunrpc/xprtrdma/rpc_rdma.c b/net/sunrpc/xprtrdma/rpc_rdma.c index c52e0f2..a524d3c 100644 --- a/net/sunrpc/xprtrdma/rpc_rdma.c +++ b/net/sunrpc/xprtrdma/rpc_rdma.c @@ -226,8 +226,10 @@ static bool rpcrdma_results_inline(struct rpcrdma_xprt *r_xprt, if (len && n == RPCRDMA_MAX_SEGS) goto out_overflow; - /* When encoding the read list, the tail is always sent inline */ - if (type == rpcrdma_readch) + /* When encoding a Read chunk, the tail iovec contains an + * XDR pad and may be omitted. + */ + if (type == rpcrdma_readch && xprt_rdma_pad_optimize) return n; /* When encoding the Write list, some servers need to see an extra @@ -238,10 +240,6 @@ static bool rpcrdma_results_inline(struct rpcrdma_xprt *r_xprt, return n; if (xdrbuf->tail[0].iov_len) { - /* the rpcrdma protocol allows us to omit any trailing - * xdr pad bytes, saving the server an RDMA operation. */ - if (xdrbuf->tail[0].iov_len < 4 && xprt_rdma_pad_optimize) - return n; n = rpcrdma_convert_kvec(&xdrbuf->tail[0], seg, n); if (n == RPCRDMA_MAX_SEGS) goto out_overflow;