On 6 Sep 2016, at 17:25, Chuck Lever wrote: >> On Sep 6, 2016, at 5:01 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: >> >> On Tue, Sep 06, 2016 at 04:49:33PM -0400, Chuck Lever wrote: >>> >>> On Sep 6, 2016, at 4:42 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: >>>> Apologies, I wasn't thinking when I wrote that patch. The problem is >>>> probably that rsc_lookup steals the passed-in memory to avoid doing an >>>> allocation of its own, so we can't just pass in a pointer to memory that >>>> someone else is using.... >>>> >>>> If we really want to avoid allocation there then maybe we should >>>> preallocate somwhere, or reference count these handles. >>>> >>>> For now reverting sounds like the right thing to do. >>> >>> NP, thanks for confirming! >>> >>> >>>> Ben, did you ever confirm whether this helped with the problem you were >>>> seeing? (If I remember correctly, unnpredictable delays here could >>>> cause the request to be dropped if later requests push the rpcsec_gss >>>> sequence window too far.) If so then we could look into reference >>>> counting. I somehow missed this; I haven't tested it. >>> Well that's interesting. >>> >>> When a request is dropped, would the server disconnect? Because if it >>> doesn't, the client will wait forever. >> >> Checking... gss_verify_header returns SVC_DROP, which is just a silent >> close (SVC_CLOSE would close the connection). >> >> I'm not sure what's correct there. > > Right, we may not get any guidance from the RPCSEC GSS specifications. > > However, the Linux NFS client retransmit code was changed in 2013 so that > NFSv4 never retransmits until the server drops the connection, starting > around commit 8a19a0b6cb2e2216afd68ef2047f30260cc8a220. That is the behavior I was seeing. Ben -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
