On Thu, Mar 31, 2022 at 08:08:59PM +0000, Trond Myklebust wrote: > On Thu, 2022-03-31 at 18:53 +0000, Chuck Lever III wrote: > > It's plausible that a deferred request could be replayed, but I don't > > understand the deferral mechanism enough to know whether the rctxt > > would be released before the deferred request could be handled. It > > doesn't look like it would, but I could misunderstand something. > > > > There's a longstanding testing gap here: None of my test workloads > > appear to force a request deferral. I don't recall Bruce having > > such a test either. > > > > It would be nice if we had something that could force the use of the > > deferral path, like a command line option for mountd that would cause > > it to sleep for several seconds before responding to an upcall. It > > might also be done with the kernel's fault injector. > > > > You just need some mechanism that causes svc_get_next_xprt() to set > rqstp->rq_chandle.thread_wait to the value '0'. Yeah, no idea what's going on here, but a way to force the deferral case sounds like a great idea that'd come in handy some day if not this time. (Can you hack it by, say, killing mountd, flushing the caches (exportfs -f), then waiting a few seconds to restart mountd?) --b.
