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...
