| Message ID | 20141220180243.GA10273@fieldses.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 12/20/14 19:02, J. Bruce Fields wrote: > Gah. Does this fix it? It does! Well done. :) Reported-by: Holger Hoffstätte <holger.hoffstaette@googlemail.com> Tested-by: Holger Hoffstätte <holger.hoffstaette@googlemail.com> Thanks! Holger -- 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
On Sat, 20 Dec 2014 13:02:43 -0500, J. Bruce Fields wrote: > On Thu, Dec 18, 2014 at 08:44:37PM +0100, Holger Hoffstätte wrote: >> On 12/18/14 18:06, J. Bruce Fields wrote: >> > Whoops, now I see, the server-side trace has the same problem, I just >> > overlooked it the first time. >> >> Excellent, so we know it's the server's fault. Really would have been >> odd to not have it in the server trace. >> >> >> ..in order to rule out a mistake on my part with the two separate >> >> runs (which prevents correlated analysis) I was just about to boot >> >> the server back into 3.18.1 and re-run both client- and server-side >> >> traces simultaneously. However I have to head out for a bit first; >> >> will post that later today. >> > >> > So this might still be interesting, but it's not a high priority. >> >> Then I guess I'll better keep my feet still and don't muddle the waters >> further, looks like you found what you need. If you still need it just >> holler. >> >> Let me know if there's anything I can do to help/patch/test! > > Gah. Does this fix it? > > A struct xdr_stream at a page boundary might point to the end of one > page or the beginning of the next, and I'm guessing xdr_truncate_encode > wasn't prepared to handle the former. > > This happens if the readdir entry that would have exceeded the client's > dircount/maxcount limit would have ended exactly on a 4k page boundary, > and inspection of the trace shows you're hitting exactly that case. > > If this does the job then I'll go figure out how to make this logic less > ugly.... > > --b. > > diff --git a/net/sunrpc/xdr.c b/net/sunrpc/xdr.c index > 1cb61242e55e..32910b91d17c 100644 --- a/net/sunrpc/xdr.c +++ > b/net/sunrpc/xdr.c @@ -630,6 +630,9 @@ void xdr_truncate_encode(struct > xdr_stream *xdr, size_t len) > > new = buf->page_base + buf->page_len; > old = new + fraglen; > + /* XXX: HACK: */ > + if (xdr->p == page_address(*xdr->page_ptr) + PAGE_SIZE) > + xdr->page_ptr++; > xdr->page_ptr -= (old >> PAGE_SHIFT) - (new >> PAGE_SHIFT); > > if (buf->page_len) { Any news on getting this upstream and into -stables? I ack'ed it on Dec. 20 and have been running it 24/7 since then with no problems. Just making sure it doesn't disappear into the post-holiday couch crack.. :) thanks, Holger -- 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/xdr.c b/net/sunrpc/xdr.c index 1cb61242e55e..32910b91d17c 100644 --- a/net/sunrpc/xdr.c +++ b/net/sunrpc/xdr.c @@ -630,6 +630,9 @@ void xdr_truncate_encode(struct xdr_stream *xdr, size_t len) new = buf->page_base + buf->page_len; old = new + fraglen; + /* XXX: HACK: */ + if (xdr->p == page_address(*xdr->page_ptr) + PAGE_SIZE) + xdr->page_ptr++; xdr->page_ptr -= (old >> PAGE_SHIFT) - (new >> PAGE_SHIFT); if (buf->page_len) {