lkml.org 
[lkml]   [2017]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: iov_iter_pipe warning.
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...

\
 
 \ /
  Last update: 2017-04-27 19:42    [W:0.150 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site