From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1756128AbdD0RkB (ORCPT <rfc822;w@1wt.eu>);
        Thu, 27 Apr 2017 13:40:01 -0400
Received: from zeniv.linux.org.uk ([195.92.253.2]:53988 "EHLO
        ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751581AbdD0Rju (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 27 Apr 2017 13:39:50 -0400
Date: Thu, 27 Apr 2017 18:39:43 +0100
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Dave Jones <davej@codemonkey.org.uk>,
        Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: iov_iter_pipe warning.
Message-ID: <20170427173943.GD29622@ZenIV.linux.org.uk>
References: <20170412022911.nhefjqlnyrk3n7rr@codemonkey.org.uk>
 <20170412025842.GO29622@ZenIV.linux.org.uk>
 <20170412143519.4hh36l3egozgdrll@codemonkey.org.uk>
 <20170412152600.GP29622@ZenIV.linux.org.uk>
 <20170412162709.bn5qfk4seues3yos@codemonkey.org.uk>
 <20170412170723.GQ29622@ZenIV.linux.org.uk>
 <20170412190318.srkkdytf2ebrjzrg@codemonkey.org.uk>
 <20170421175430.GT29622@ZenIV.linux.org.uk>
 <20170427041918.ts33j22wm352xjni@codemonkey.org.uk>
 <20170427163444.6pbuyhgasydvtj24@codemonkey.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170427163444.6pbuyhgasydvtj24@codemonkey.org.uk>
User-Agent: Mutt/1.7.1 (2016-10-04)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Apr 27, 2017 at 12:34:44PM -0400, Dave Jones wrote:

> [977286.117268] RPC request reserved 116 but used 268
> [1918138.126285] RPC request reserved 200 but used 268
> [2327777.483077] RPC request reserved 200 but used 268
> [2327800.909007] RPC request reserved 200 but used 268
> 
> related ?

Rather unlikely...  AFAICS, that's nfsd miscalculating the response
size and generating longer response than it has reserved.  The warning
comes from svc_xprt_release().  Out of its callers, svc_recv() is
impossible (it zeroes rqstp->rq_res.len before calling the sucker, so
there's no way for it to be found too large), which leaves svc_drop()
and svc_send().  The last one is more likely, AFAICS, and there the
length is calculated by
        /* calculate over-all length */
        xb = &rqstp->rq_res;
        xb->len = xb->head[0].iov_len +
                xb->page_len +
                xb->tail[0].iov_len;

Might be interesting to slap WARN_ON(xb->len > rqstp->rq_reserved); there
and see if it triggers.  Or something like
	if (WARN_ON(rqstp->rq_res->head[0].iov_len +
		rqstp->rq_res->page_len +
		rqstp->rq_res->tail[0].iov_len > rqstp->rq_reserved) {
		try to print something useful about request and response
	}
right before the call of ->xpo_release_rqst() in there - I hadn't looked
at that code for a long time, but it smells like dumping the request is
better done before the skbs containing it get dropped...