netdev - Re: [PATCH v2 net-next] tcp: introduce a new MIB for CLOSE-WAIT sockets

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAL+tcoCcNGVkxVapYTVy1yx3OJep5uZaD+yqJGdVoriutUmLqQ@mail.gmail.com>
Date: Wed, 29 May 2024 23:52:25 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: dsahern@...nel.org, kuba@...nel.org, pabeni@...hat.com, 
	davem@...emloft.net, netdev@...r.kernel.org, 
	Jason Xing <kernelxing@...cent.com>, Yongming Liu <yomiliu@...cent.com>, 
	Wangzi Yong <curuwang@...cent.com>
Subject: Re: [PATCH v2 net-next] tcp: introduce a new MIB for CLOSE-WAIT sockets

Hello Eric，

On Wed, May 29, 2024 at 11:42 PM Eric Dumazet <edumazet@...gle.com> wrote:
>
> On Wed, May 29, 2024 at 5:31 AM Jason Xing <kerneljasonxing@...il.com> wrote:
> >
> > From: Jason Xing <kernelxing@...cent.com>
> >
> > CLOSE-WAIT is a relatively special state which "represents waiting for
> > a connection termination request from the local user" (RFC 793). Some
> > issues may happen because of unexpected/too many CLOSE-WAIT sockets,
> > like user application mistakenly handling close() syscall. It's a very
> > common issue in the real world.
> >
> > We want to trace this total number of CLOSE-WAIT sockets fastly and
> > frequently instead of resorting to displaying them altogether by using:
> >
> >   ss -s state close-wait
> >
> > or something like this. They need to loop and collect required socket
> > information in kernel and then get back to the userside for print, which
> > does harm to the performance especially in heavy load for frequent
> > sampling.
> >
> > That's the reason why I chose to introduce this new MIB counter like
> > CurrEstab does. With this counter implemented, we can record/observe the
> > normal changes of this counter all the time. It can help us:
> > 1) We are able to be alerted in advance if the counter changes drastically.
> > 2) If some users report some issues happening, we will particularly
> > pay more attention to it.
> >
> > Besides, in the group of TCP_MIB_* defined by RFC 1213, TCP_MIB_CURRESTAB
> > should include both ESTABLISHED and CLOSE-WAIT sockets in theory:
> >
>
> We (Neal and myself) prefer to fix TCP_MIB_CURRESTAB to include
> CLOSE_WAIT sockets.
> We do not think it will annoy anyone, please change tcp_set_state() accordingly.

Thanks for your reply. Honestly, I was worried about what you said.
Now, I'm relieved.

It seems that I should add a Fixes: tag...

>
> Rationale is that adoption of a new MIB in documentations and various
> products will take years.
>
> Also make a similar change for mptcp.

I will check that part tomorrow morning, too.

Thank you :)

Jason