On 2 Feb 2024, at 12:45, Olga Kornievskaia wrote: > On Fri, Feb 2, 2024 at 12:05 PM Olga Kornievskaia < > olga.kornievskaia@xxxxxxxxx> wrote: > >> >> >> On Fri, Feb 2, 2024 at 11:56 AM Benjamin Coddington <bcodding@xxxxxxxxxx> >> wrote: >> >>> 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. >>> >> >> :) I'll send a v3. though I don't see my v2 posted but i did send it >> already. >> > > Well looks like I'm not longer able to submit patches because of something > new fancy policies. I have used the same gitemail from mac as v1 and now my > emails are rejected. I use Mac's git sendmail command. > > Ben, how do you submit to your patches, do you use Mac git's or submit > through something else? Thank you for the help. I use git send-email from linux and I relay through redhat.com's smtp servers, which are generally well-trusted. Your v2 made it to me and the archives: https://lore.kernel.org/linux-nfs/20240202145432.95487-1-olga.kornievskaia@xxxxxxxxx/T/#u Ben
