On Mon, Jan 22, 2018 at 11:12:13PM +0100, Mike Belopuhov wrote:
> There's nothing wrong with diagnostics of course, but at the same time,
> if there's no bug to hunt why bother? I'm certain you've tried the diff
> yourself and it didn't blow up, otherwise we wouldn't be having this
> conversation.
)
> 2) additional check for TCP_TIMER_ISARMED(TCPT_REXMT) in tcp_timer_persist()
> with mickey@; ok deraadt@
>
> > > The tcp reaper timeout is still imlemented as soft timeout. So it
> > > can run while net lock is held by others and it is not synchronized
> > >
ocation for timer and network input
1) add a reaper for TCP and SYN cache states (cf. netbsd pr 20390)
2) additional check for TCP_TIMER_ISARMED(TCPT_REXMT) in tcp_timer_persist()
with mickey@; ok deraadt@
> > The tcp reaper timeout is still imlemented as soft timeout. So it
> > can r
On Sat, Jan 20, 2018 at 15:17 +0100, Alexander Bluhm wrote:
> Hi,
>
Hi,
While I'm not against making all TCP timeouts look similar, I'd like
to understand if there's any other reason to do it other than
"consistency".
> The tcp reaper timeout is still imleme
Hi,
The tcp reaper timeout is still imlemented as soft timeout. So it
can run while net lock is held by others and it is not synchronized
with the other tcp timeouts. Convert it to an ordinary tcp timeout
so it is scheduled on the same timeout thread. It grabs the net
lock to make sure that
