Re: tcp_close: can we delay the reaper for 1 tick?

[Alexander Bluhm]

On Fri, Jul 24, 2020 at 01:20:29PM -0500, Scott Cheloha wrote:
> tcp_close() schedules the reaper timeout to run immediately.
> Does it need to run *immediately*?  Can it wait for one tick?

It does not matter.  Free has to happen after timeout thread has
been run.  Some other timeout may be waiting for netlock and reference
the TCB.  So I added the delay.

Just don't wait too long to avoid wasting resources.

OK bluhm@

> Index: tcp_subr.c
> ===
> RCS file: /cvs/src/sys/netinet/tcp_subr.c,v
> retrieving revision 1.174
> diff -u -p -r1.174 tcp_subr.c
> --- tcp_subr.c4 Oct 2018 17:33:41 -   1.174
> +++ tcp_subr.c24 Jul 2020 18:19:00 -
> @@ -518,7 +518,7 @@ tcp_close(struct tcpcb *tp)
>  
>   m_free(tp->t_template);
>   /* Free tcpcb after all pending timers have been run. */
> - TCP_TIMER_ARM(tp, TCPT_REAPER, 0);
> + TCP_TIMER_ARM(tp, TCPT_REAPER, 1);
>  
>   inp->inp_ppcb = NULL;
>   soisdisconnected(so);

tcp_close: can we delay the reaper for 1 tick?

[Scott Cheloha]

tcp_close() schedules the reaper timeout to run immediately.

Does it need to run *immediately*?  Can it wait for one tick?

I'm trying to eliminate these zero-tick timeouts because they
rely on undocumented behavior and impede an optimization I want
to make in the timeout layer.

This is the one I'm hitting most often so I'll start here.

Index: tcp_subr.c
===
RCS file: /cvs/src/sys/netinet/tcp_subr.c,v
retrieving revision 1.174
diff -u -p -r1.174 tcp_subr.c
--- tcp_subr.c  4 Oct 2018 17:33:41 -   1.174
+++ tcp_subr.c  24 Jul 2020 18:19:00 -
@@ -518,7 +518,7 @@ tcp_close(struct tcpcb *tp)
 
m_free(tp->t_template);
/* Free tcpcb after all pending timers have been run. */
-   TCP_TIMER_ARM(tp, TCPT_REAPER, 0);
+   TCP_TIMER_ARM(tp, TCPT_REAPER, 1);
 
inp->inp_ppcb = NULL;
soisdisconnected(so);