All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guillaume Nault <gnault@redhat.com>
To: Kuniyuki Iwashima <kuniyu@amazon.com>
Cc: dsahern@gmail.com, edumazet@google.com, mkubecek@suse.cz,
	netdev@vger.kernel.org
Subject: Re: [PATCH iproute2-next] ss: Add support for dumping TCP bound-inactive sockets.
Date: Mon, 11 Dec 2023 18:58:47 +0100	[thread overview]
Message-ID: <ZXdN14BQwrUcpbgt@debian> (raw)
In-Reply-To: <20231211141917.42613-1-kuniyu@amazon.com>

On Mon, Dec 11, 2023 at 11:19:17PM +0900, Kuniyuki Iwashima wrote:
> > diff --git a/misc/ss.c b/misc/ss.c
> > index 16ffb6c8..19adc1b7 100644
> > --- a/misc/ss.c
> > +++ b/misc/ss.c
> > @@ -210,6 +210,8 @@ enum {
> >  	SS_LAST_ACK,
> >  	SS_LISTEN,
> >  	SS_CLOSING,
> > +	SS_NEW_SYN_RECV,
> 
> I think this is bit confusing as TCP_NEW_SYN_RECV is usually
> invisible from user.
> 
> TCP_NEW_SYN_RECV was originally split from TCP_SYN_RECV for a
> non-{TFO,cross-SYN} request.
> 
> So, both get_openreq4() (/proc/net/tcp) and inet_req_diag_fill()
> (inet_diag) maps TCP_NEW_SYN_RECV to TCP_SYN_RECV.

I think we need to explicitely set SS_NEW_SYN_RECV anyway, because we
have to set its entry in the sstate_namel array in scan_state().

But I can add a comment like this:
@@ -210,6 +210,8 @@ enum {
 	SS_LAST_ACK,
 	SS_LISTEN,
 	SS_CLOSING,
+	SS_NEW_SYN_RECV, /* Kernel only value, not for use in user space */
+	SS_BOUND_INACTIVE,
 	SS_MAX
 };

> > +	SS_BOUND_INACTIVE,
> 
> I prefer explicitly assigning a number to SS_BOUND_INACTIVE.
> 
> 
> >  	SS_MAX
> >  };
> >  
> > @@ -1382,6 +1384,8 @@ static void sock_state_print(struct sockstat *s)
> >  		[SS_LAST_ACK] = "LAST-ACK",
> >  		[SS_LISTEN] =	"LISTEN",
> >  		[SS_CLOSING] = "CLOSING",
> > +		[SS_NEW_SYN_RECV] = "NEW-SYN-RECV",
> 
> If we need to define SS_NEW_SYN_RECV, I prefer not setting
> it or setting "" or "SYN-RECV".

I originally considered the string wasn't important as the kernel isn't
supposed to return this value. But I agree we can do better.

I don't really like "SYN-RECV" though, as I find it even more confusing.
I'd prefer your other proposal using "", or maybe "UNDEF", together with
a comment saying something like "Never returned by kernel".

> > +		[SS_BOUND_INACTIVE] = "BOUND-INACTIVE",

And whatever we decide for SS_NEW_SYN_RECV, we can apply the same to
SS_BOUND_INACTIVE, since the kernel isn't supposed set this state on
output too.

So we'd have something like:
@@ -1382,6 +1384,8 @@ static void sock_state_print(struct sockstat *s)
 		[SS_LAST_ACK] = "LAST-ACK",
 		[SS_LISTEN] =	"LISTEN",
 		[SS_CLOSING] = "CLOSING",
+		[SS_NEW_SYN_RECV] = "UNDEF", /* Never returned by kernel */
+		[SS_BOUND_INACTIVE] = "UNDEF", /* Never returned by kernel */
 	};

> > @@ -5421,6 +5426,8 @@ static int scan_state(const char *state)
> >  		[SS_LAST_ACK] = "last-ack",
> >  		[SS_LISTEN] =	"listening",
> >  		[SS_CLOSING] = "closing",
> > +		[SS_NEW_SYN_RECV] = "new-syn-recv",
> 
> Same here.

Well, here, whatever we do, the string associated with SS_NEW_SYN_RECV
will be usable by the user. So I'd prefer to have a specific and
unambiguous string and then explicitly refuse it.

What do you think of something like the following?

@@ -5421,9 +5426,17 @@ static int scan_state(const char *state)
 		[SS_LAST_ACK] = "last-ack",
 		[SS_LISTEN] =	"listening",
 		[SS_CLOSING] = "closing",
+		[SS_NEW_SYN_RECV] = "new-syn-recv",
+		[SS_BOUND_INACTIVE] = "bound-inactive",
 	};
 	int i;
 
+	/* NEW_SYN_RECV is a kernel implementation detail. It shouldn't be used
+	 * or even be visible to the user.
+	 */
+	if (strcasecmp(state, "new-syn-recv") == 0)
+		goto wrong_state;
+
 	if (strcasecmp(state, "close") == 0 ||
 	    strcasecmp(state, "closed") == 0)
 		return (1<<SS_CLOSE);
@@ -5446,6 +5459,7 @@ static int scan_state(const char *state)
 			return (1<<i);
 	}
 
+wrong_state:
 	fprintf(stderr, "ss: wrong state name: %s\n", state);
 	exit(-1);
 }


  reply	other threads:[~2023-12-11 17:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-11 13:35 [PATCH iproute2-next] ss: Add support for dumping TCP bound-inactive sockets Guillaume Nault
2023-12-11 14:19 ` Kuniyuki Iwashima
2023-12-11 17:58   ` Guillaume Nault [this message]
2023-12-13 17:16   ` David Ahern

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=ZXdN14BQwrUcpbgt@debian \
    --to=gnault@redhat.com \
    --cc=dsahern@gmail.com \
    --cc=edumazet@google.com \
    --cc=kuniyu@amazon.com \
    --cc=mkubecek@suse.cz \
    --cc=netdev@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.