Can you explain a bit more about the rationale?

Abandoning, as this doesn't seem to get any traction with maintainers of docs

manual close, as commit didn't auto.close

Is this the primary suspect for the mbuf leak issue around the socket upcall() handling?

forget my last comment, I was looking on the wrong side of the screen or whatever. looks good.

• restricting t_dupacks calculations to not overflow
• restrict further to a static comparison rather a dynamic

• add relevant comment

Always this pesky FIN bit in the sequence space... :)

discussed in transport call.

Where are the ip options accounted for, then? Is the mbuf already adjusted to no longer contain ipoptions by that time (not familiar with IP level processing).

• rebase to main
• remove WAKESOW after major RACK update again

On a related note: do the makefiles fetch the current tzinfo files automatically, when building world/universe? (official repository now at https://www.iana.org/time-zones )

• rebase

• add statisticts to see when lrd triggered
• add sockopt TCP_LRD for a/B testing

• rebase without D29441
• make magic values human-readable

no magic numbers in sack-changed.

Certainly. While fixing the socket buffer upcall / SACK interaction (29290) the large swath of missing tabs got on me :)

• remove unlock from tcp_reass() and more logging

In D29992#672920, @mav wrote:

I am not sure how useful it is to report only SMART status. I barely remember any cases when SMART reported actual error. Much more often we start replacing drives preventivelywhen they start reallocating and loose performance.

• do not bail out of upcall for disconnected socket
• track each lingering wakeup call

• add man page for net.inet.tcp.do_lrd

transport call: fence this new functionality behind a sysctl until stability has been demonstrated

Thank you. Ideally, you should obviouly no longer expirience any hungs, but also the dmesg should be void of any entries like "WAKESOR left over" or "handling WAKESOR finally".

This diff is currently WIP - with extra logging scattered, and not all remnants, where tcp_handle_wakeup() is called, removed. The reason is that I lack an environemnt in which the Problem around NFS server becoming unresponsive, or entering a RST fight, can be replicated.

• reduce so_rcv lock time as much as possible

• relax criteria when to move left the rescue hole

in stable-13, this is all gated with net.inet.tcp.rfc6675_pipe, defaulted to disabled.

I did observe these leftovers locally also, but in both instances when there is a tcp state transition to closing / fin_wait. Do you see any odd timing now - e.g the server or client taking longer for a reconnect when the L2 and client interface are severed and restored?

• remove unlock from tcp_reass() and more logging
• address lock order reversal by doing the upcall before tcp_output() calls

• add TF2_ECN_PLUSPLUS flag to reduce cacheline churn in fastpath when checking V_ecn_generalized

• remove sysctlproc with hint, only mention change in man page

• also do this for rack and bbr

In D29690#668536, @rmacklem wrote:

I get a panic "_mtx_lock_sleep: recursed on non-recursive mutex"
when socantrcvmore() does SOCKBUF_LOCK() with this patch.

It was only on-screen, but here's the stack trace:
mtx_lock_sleep
mtx_lock_flags
socantrcvmore
tcp_do_seqment

• deal with pending upcall on FIN correctly