From: Jason Xing <kerneljasonxing@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
dsahern@kernel.org, matttbe@kernel.org, martineau@kernel.org,
geliang@kernel.org, pabeni@redhat.com, davem@davemloft.net,
mhiramat@kernel.org, mathieu.desnoyers@efficios.com,
atenart@kernel.org, mptcp@lists.linux.dev,
netdev@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
Jason Xing <kernelxing@tencent.com>
Subject: Re: [PATCH net-next v6 0/7] Implement reset reason mechanism to detect
Date: Sat, 20 Apr 2024 11:22:32 +0800 [thread overview]
Message-ID: <CAL+tcoBS1pAp-1sKE8V9CHEXqwme2-eRvwJtL150mGqmD+7hpQ@mail.gmail.com> (raw)
In-Reply-To: <20240419223553.49cb0628@rorschach.local.home>
Hello Steven,
On Sat, Apr 20, 2024 at 10:36 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Fri, 19 Apr 2024 16:00:20 +0800
> Jason Xing <kerneljasonxing@gmail.com> wrote:
>
> > If other experts see this thread, please help me. I would appreciate
> > it. I have strong interests and feel strong responsibility to
> > implement something like this patch series. It can be very useful!!
>
> I'm not a networking expert, but as I'm Cc'd and this is about tracing,
> I'll jump in to see if I can help. Honestly, reading the thread, it
> appears that you and Eric are talking past each other.
>
> I believe Eric is concerned about losing the value of the enum. Enums
> are types, and if you typecast them to another type, they lose the
> previous type, and all the safety that goes with it.
Ah, I see. Possible lost value in another enum could cause a problem.
>
> Now, I do not really understand the problem trying to be solved here. I
> understand how TCP works but I never looked into the implementation of
> MPTCP.
>
> You added this:
>
> +static inline enum sk_rst_reason convert_mptcp_reason(u32 reason)
> +{
> + return reason += RST_REASON_START;
> +}
>
> And used it for places like this:
>
> @@ -309,8 +309,13 @@ static struct dst_entry *subflow_v4_route_req(const struct sock *sk,
> return dst;
>
> dst_release(dst);
> - if (!req->syncookie)
> - tcp_request_sock_ops.send_reset(sk, skb, SK_RST_REASON_NOT_SPECIFIED);
> + if (!req->syncookie) {
> + struct mptcp_ext *mpext = mptcp_get_ext(skb);
> + enum sk_rst_reason reason;
> +
> + reason = convert_mptcp_reason(mpext->reset_reason);
> + tcp_request_sock_ops.send_reset(sk, skb, reason);
> + }
> return NULL;
> }
>
> As I don't know this code or how MPTCP works, I do not understand the
> above. It use to pass to send_reset() SK_RST_REASON_NOT_SPECIFIED. But
> now it takes a "reset_reason" calls the "convert_mptcp_reason()" to get
> back a enum value.
>
> If you are mapping the reset_reason to enum sk_rst_reason, why not do
> it via a real conversion instead of this fragile arithmetic between the two
> values?
>
> static inline enum sk_rst_reason convert_mptcp_reason(u32 reason)
> {
> switch(reason) {
> case 0: return SK_RST_REASON_MPTCP_RST_EUNSPEC;
> case 1: return SK_RST_REASON_MPTCP_RST_EMPTCP;
> case 2: return SK_RST_REASON_MPTCP_RST_ERESOURCE;
> [..]
> default: return SK_RST_REASON_MAX; // or some other error value
> ]
> }
This code snippet looks much better than mine.
>
> I'm not sure if this is any better, but it's not doing any casting and
> it's easier to understand. It's a simple mapping between the reason and
> the enum and there's no inherit dependency between the values. Could
> possibly create enums for the reason numbers and replace the hard coded
> values with them.
Right.
I also need to handle many drop reasons cases like what you do. Due to
too many of them, I will try the key-value map instead of switch-case
and then see if it works.
>
> That way that helper function is at least doing a real conversion of
> one type to another.
>
> But like I said from the beginning. I don't understand the details here
> and have not spent the time to dig deeper. I just read the thread and I
> agree with Eric that the arithmetic conversion of reason to an enum
> looks fragile at best and buggy at worst.
Thanks so much for your help, which I didn't even imagine.
Sure, after one night of investigation, I figured it out. I will drop
enum casts without any doubt as Eric and you suggested. But I believe
a new enum is needed, grouping various reasons together which help
ftrace print the valid string to userspace.
Thanks,
Jason
>
> -- Steve
prev parent reply other threads:[~2024-04-20 3:23 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-17 8:51 [PATCH net-next v6 0/7] Implement reset reason mechanism to detect Jason Xing
2024-04-17 8:51 ` [PATCH net-next v6 1/7] net: introduce rstreason to detect why the RST is sent Jason Xing
2024-04-17 9:01 ` Eric Dumazet
2024-04-17 9:22 ` Jason Xing
2024-04-17 8:51 ` [PATCH net-next v6 2/7] rstreason: prepare for passive reset Jason Xing
2024-04-17 8:51 ` [PATCH net-next v6 3/7] rstreason: prepare for active reset Jason Xing
2024-04-17 8:51 ` [PATCH net-next v6 4/7] tcp: support rstreason for passive reset Jason Xing
2024-04-17 8:51 ` [PATCH net-next v6 5/7] mptcp: " Jason Xing
2024-04-17 8:51 ` [PATCH net-next v6 6/7] mptcp: introducing a helper into active reset logic Jason Xing
2024-04-17 8:51 ` [PATCH net-next v6 7/7] rstreason: make it work in trace world Jason Xing
2024-04-17 9:41 ` [PATCH net-next v6 0/7] Implement reset reason mechanism to detect MPTCP CI
2024-04-18 3:30 ` Jason Xing
2024-04-18 15:46 ` Jakub Kicinski
2024-04-18 16:23 ` Jason Xing
2024-04-18 18:51 ` Eric Dumazet
2024-04-18 22:29 ` Jason Xing
2024-04-18 22:40 ` Jason Xing
2024-04-18 23:26 ` Jason Xing
2024-04-19 2:30 ` Jason Xing
2024-04-19 7:02 ` Eric Dumazet
2024-04-19 7:28 ` Jason Xing
2024-04-19 7:44 ` Eric Dumazet
2024-04-19 8:00 ` Jason Xing
2024-04-19 8:06 ` Jason Xing
2024-04-20 2:35 ` Steven Rostedt
2024-04-20 3:22 ` Jason Xing [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAL+tcoBS1pAp-1sKE8V9CHEXqwme2-eRvwJtL150mGqmD+7hpQ@mail.gmail.com \
--to=kerneljasonxing@gmail.com \
--cc=atenart@kernel.org \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=geliang@kernel.org \
--cc=kernelxing@tencent.com \
--cc=kuba@kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=martineau@kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=matttbe@kernel.org \
--cc=mhiramat@kernel.org \
--cc=mptcp@lists.linux.dev \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).