> On Sep 6, 2016, at 7:49 PM, Benjamin Coddington <bcodding@xxxxxxxxxx> wrote: > > 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. I have a reproducer that is somewhat reliable. I will try using SVC_CLOSE. -- 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
