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