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". Ben
