From patchwork Wed Nov 9 19:05:05 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chuck Lever X-Patchwork-Id: 9420041 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 7AACC60585 for ; Wed, 9 Nov 2016 19:05:09 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6E66E293B7 for ; Wed, 9 Nov 2016 19:05:09 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 634F5293C4; Wed, 9 Nov 2016 19:05:09 +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.3 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, 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 EE2CA293B7 for ; Wed, 9 Nov 2016 19:05:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753162AbcKITFH (ORCPT ); Wed, 9 Nov 2016 14:05:07 -0500 Received: from mail-it0-f67.google.com ([209.85.214.67]:36658 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753108AbcKITFH (ORCPT ); Wed, 9 Nov 2016 14:05:07 -0500 Received: by mail-it0-f67.google.com with SMTP id n68so16385452itn.3; Wed, 09 Nov 2016 11:05:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:from:to:date:message-id:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=SYx2kElyoKi9LkMWQfwy/KrgO3E7xx55zsI9VOYioLQ=; b=pFjt1aI+oyEeaz1un4HJquCdUrbfdIt5Oy7rHpfeJR1J9qo/0wkotFPVlhnXBqvapM XdGoPcqZFbZdV22SXtguLBZYo7D7/nkIgWdQC+/tVQpEfboPOg+jbgoPbEMgQmUQhFhD sQ+K0yHHPShKCJ6Tv/bus88C562rPZfBnBJmS2o1O2WCWr6W8HhdvHzqanEqnAM2PR5A oNTKiKaGImSrQKojUuaQlMGjC3XdzuI96NHTirJOTHvszU+Tzzt7pEOFhE1GBm43LAmd 9P9DrT/5djl9i0l2TNsk3erPBpiIMnG59z/3tjKyVtt9xHomjG/M7kx6GkQF0rT8/leZ QAXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:from:to:date:message-id :in-reply-to:references:user-agent:mime-version :content-transfer-encoding; bh=SYx2kElyoKi9LkMWQfwy/KrgO3E7xx55zsI9VOYioLQ=; b=gaZZsRSxZzNDst6G41U3q/sGH/+5HHsw3eaSHLnexure3HtEsrSuAkvCId5WM8xy4f HOqgBznYVyRQtt4PM1S7TAOf5pZTZBa2w31usaz9JTRAP+1VQeaGB25tymyPmHSlY5BV EIdnR4JGb480kQS9yvU7bHzGHIMMPWY6jYU5TKmiEK+/qzTJAB7Xik+kncDAuVfBvncM DV7smoB5MK6hlbXDvtgA4cvY2NMx3FHqROYN2f5UcnIbfyRIMfjl29AVHzfLkRW0fwwE BTOWd1Pt4phKYtiacEXNfQe6IWEnbWmWRGDqJbtnMBRCazO9vPHZ0LXJuAeBjjJ9Q5Uy nCeA== X-Gm-Message-State: ABUngvdOc1yOg3Z/mmm8HZnJbVhYeBlNVkNkG+SWrK5WEEaRaFmdz6OByzACzWZOFnfHCA== X-Received: by 10.36.61.212 with SMTP id n203mr14613368itn.79.1478718306062; Wed, 09 Nov 2016 11:05:06 -0800 (PST) Received: from manet.1015granger.net ([2604:8800:100:81fc:ec4:7aff:fe6c:1dce]) by smtp.gmail.com with ESMTPSA id i75sm6657633itf.10.2016.11.09.11.05.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Nov 2016 11:05:05 -0800 (PST) Subject: [PATCH v1 02/14] xprtrdma: Cap size of callback buffer resources From: Chuck Lever To: linux-rdma@vger.kernel.org, linux-nfs@vger.kernel.org Date: Wed, 09 Nov 2016 14:05:05 -0500 Message-ID: <20161109190505.15007.42767.stgit@manet.1015granger.net> In-Reply-To: <20161109184735.15007.96507.stgit@manet.1015granger.net> References: <20161109184735.15007.96507.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 the inline threshold size is set to large values (say, 32KB) any NFSv4.1 CB request from the server gets a reply with status NFS4ERR_RESOURCE. Looks like there are some upper layer assumptions about the maximum size of a reply (for example, in process_op). Cap the size of the NFSv4 client's reply resources at a page. Signed-off-by: Chuck Lever --- net/sunrpc/xprtrdma/backchannel.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 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/backchannel.c b/net/sunrpc/xprtrdma/backchannel.c index 2c472e1..24fedd4 100644 --- a/net/sunrpc/xprtrdma/backchannel.c +++ b/net/sunrpc/xprtrdma/backchannel.c @@ -55,7 +55,8 @@ static int rpcrdma_bc_setup_rqst(struct rpcrdma_xprt *r_xprt, if (IS_ERR(rb)) goto out_fail; req->rl_sendbuf = rb; - xdr_buf_init(&rqst->rq_snd_buf, rb->rg_base, size); + xdr_buf_init(&rqst->rq_snd_buf, rb->rg_base, + min_t(size_t, size, PAGE_SIZE)); rpcrdma_set_xprtdata(rqst, req); return 0; @@ -191,6 +192,7 @@ size_t xprt_rdma_bc_maxpayload(struct rpc_xprt *xprt) size_t maxmsg; maxmsg = min_t(unsigned int, cdata->inline_rsize, cdata->inline_wsize); + maxmsg = min_t(unsigned int, maxmsg, PAGE_SIZE); return maxmsg - RPCRDMA_HDRLEN_MIN; }