> On Mar 12, 2019, at 2:41 PM, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote: > > On Tue, 2019-03-12 at 10:47 -0400, Chuck Lever wrote: >>> On Mar 12, 2019, at 10:36 AM, Olga Kornievskaia <aglo@xxxxxxxxx> >>> wrote: >>> >>> On Tue, Mar 12, 2019 at 10:33 AM Chuck Lever < >>> chuck.lever@xxxxxxxxxx> wrote: >>>> >>>> >>>>> On Mar 12, 2019, at 10:29 AM, Olga Kornievskaia <aglo@xxxxxxxxx >>>>>> wrote: >>>>> >>>>> Hi Chuck, >>>>> >>>>> Is this a known issue? >>>> >>>> Nope. >>> >>> Ok. >>> Looks like anything to do with callback channeling trying to use >>> the >>> trace_event_raw_event_xprt_transmit.... >> >> Callback rqst's are missing either an rq_task or rq_task->tk_client >> (I can't remember at the moment). It would be nicer for the forward >> channel infrastructure if such rqst's were complete... >> >> Otherwise, trace_xprt_transmit and trace_xprt_enq_xmit need to check >> if task and task->tk_client are present before dereferencing them. > > Back channel tasks have no associated task->tk_client. They are owned > by a server task, not by a client. Understood, I'm simply suggesting that there could be a "phony" client for callbacks so that other code doesn't have to check to see if tk_client is populated before dereferencing it. > In either case, the transport code should avoid concerning itself with > the client structure. That's a higher layer object. Right. The only reason the transport is concerning itself with tk_client is the task:%u@%u identifier in trace points. I would think that, for instance, someone adding an ad hoc kprobe would want to avoid a fault here, but would have to know that callback rqst's passing through the forward channel code do not have a tk_client. -- Chuck Lever
