Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Subject: Re: oops on a sunrpc tracepoint
From:   Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <277d2273a5e6c34a5898fab7dd6b019e43968a40.camel@hammerspace.com>
Date:   Tue, 12 Mar 2019 14:54:20 -0400
Cc:     Olga Kornievskaia <aglo@umich.edu>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <08FD3CD9-BED8-4D76-8FF5-EBFC0A5A7AA2@oracle.com>
References: <CAN-5tyFt0j9g4iTzoT-HqzKLDvMqq+x1=PxWPBHzAd3seyaqcQ@mail.gmail.com>
 <69C7D007-BA4A-4711-8024-57B26F5BAE5E@oracle.com>
 <CAN-5tyED+23WxH3z_yoEGaRaica8DMhKaO+pYOstbU7P=Y6whg@mail.gmail.com>
 <959FF86E-32E0-45CA-A05A-0AEAF8F802B4@oracle.com>
 <277d2273a5e6c34a5898fab7dd6b019e43968a40.camel@hammerspace.com>
To:     Trond Myklebust <trondmy@hammerspace.com>
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk


> On Mar 12, 2019, at 2:41 PM, Trond Myklebust <trondmy@hammerspace.com> =
wrote:
>=20
> On Tue, 2019-03-12 at 10:47 -0400, Chuck Lever wrote:
>>> On Mar 12, 2019, at 10:36 AM, Olga Kornievskaia <aglo@umich.edu>
>>> wrote:
>>>=20
>>> On Tue, Mar 12, 2019 at 10:33 AM Chuck Lever <
>>> chuck.lever@oracle.com> wrote:
>>>>=20
>>>>=20
>>>>> On Mar 12, 2019, at 10:29 AM, Olga Kornievskaia <aglo@umich.edu
>>>>>> wrote:
>>>>>=20
>>>>> Hi Chuck,
>>>>>=20
>>>>> Is this a known issue?
>>>>=20
>>>> Nope.
>>>=20
>>> Ok.
>>> Looks like anything to do with callback channeling trying to use
>>> the
>>> trace_event_raw_event_xprt_transmit....
>>=20
>> 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...
>>=20
>> Otherwise, trace_xprt_transmit and trace_xprt_enq_xmit need to check
>> if task and task->tk_client are present before dereferencing them.
>=20
> 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