On 2 Feb 2024, at 11:47, Olga Kornievskaia wrote: > On Fri, Feb 2, 2024 at 10:36 AM Benjamin Coddington <bcodding@xxxxxxxxxx> > wrote: > >> On 2 Feb 2024, at 9:42, Olga Kornievskaia wrote: >> >>> On Fri, Feb 2, 2024 at 8:01 AM Benjamin Coddington <bcodding@xxxxxxxxxx> >> wrote: >>>> >>>> On 26 Jan 2024, at 14:03, Olga Kornievskaia wrote: >>>> >>>>> From: Olga Kornievskaia <kolga@xxxxxxxxxx> >>>>> >>>>> Add a tracepoint to track when the client sends EXCHANGE_ID to test >>>>> a new transport for session trunking. >>>>> >>>>> Signed-off-by: Olga Kornievskaia <kolga@xxxxxxxxxx> >>>>> --- >>>>> fs/nfs/nfs4proc.c | 3 +++ >>>>> fs/nfs/nfs4trace.h | 30 ++++++++++++++++++++++++++++++ >>>>> 2 files changed, 33 insertions(+) >>>>> >>>>> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c >>>>> index 23819a756508..cdda7971c945 100644 >>>>> --- a/fs/nfs/nfs4proc.c >>>>> +++ b/fs/nfs/nfs4proc.c >>>>> @@ -8974,6 +8974,9 @@ void nfs4_test_session_trunk(struct rpc_clnt >> *clnt, struct rpc_xprt *xprt, >>>>> status = nfs4_detect_session_trunking(adata->clp, >>>>> task->tk_msg.rpc_resp, xprt); >>>>> >>>>> + trace_nfs4_trunked_exchange_id(adata->clp, >>>>> + xprt->address_strings[RPC_DISPLAY_ADDR], status); >>>>> + >>>> >>>> Any worry about the ambiguity of whether "status" comes from tk_status >> or >>>> from nfs4_detect_session_trunking() here? The latter can return -EINVAL >>>> which isn't in show_nfs4_status(). >>> >>> Good catch, I didn't realize there wasn't an EINVAL mapping. I was >>> focusing on capturing the fact that exchangeid was happening and ip >>> info of the trunking connection that I didn't pay attention to the >>> status. I'll send a v2 with EINVAL added to show_nfs4_status. >> >> If you're only interested in tk_status, you could just move the tracepoint. >> That would resolve the conditional branch that changes the source of >> "status". >> > > We are not interested in tk_status that can be gotten from the > nfs4_xdr_status tracepoint. We are interested in the results of the > trunking decision. Gotcha, ok, I understand now. Tucking into the conditional or moving it into nfs4_detect_session_trunking() would make that clearer, but no big objection from me. If the task returns an error, this tracepoint will still be called with tk_status instead of any result from the trunking decision. Ben
