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. > Otherwise, looks good to me. > > Reviewed-by: Benjamin Coddington <bcodding@xxxxxxxxxx> > > Ben >
