This is the source comment that should have been submitted with my 'request for change' action, had I pressed the buttons in a way that didn't dispose of it instead.

Adjusted label names and comments

In D8218#170900, @jtl wrote:

In D8218#170887, @pkelsey wrote:

This is functionally equivalent, but I don't think it is clearer. I think it is less clear that the conditional decrement is placed after the tfo_done label as it will never execute after a goto tfo_done.

I placed it there as a matter of future-proofing. It doesn't hurt anything for it to be after the tfo_done label. But, if someone makes a code change to add a new goto tfo_done, it will still hit this check.

Because you obviously have strong feelings for exactly how this code should be (and this doesn't really impact me), I've opened a bug and assigned it to you. You can fix it at your convenience.

This is functionally equivalent, but I don't think it is clearer. I think it is less clear that the conditional decrement is placed after the tfo_done label as it will never execute after a goto tfo_done. There is clear one-to-one correspondence between creating a TFO socket and not needing this decrement that I think is blurred by this positioning because the decrement is not an action that is common to 'done' and 'tfo_done', it is unique to 'done'. I think we would be better off if the code wasn't arranging to cancel a conditional action because it was placed in a path it never needs to be in.

In D8218#170623, @jtl wrote:

In D8218#170606, @pkelsey wrote:

I can only identify one circumstance where the t_tfo_pending counter on a listen socket will be incremented without a corresponding decrement ever occurring - when all of the following conditions are met:

1. TFO is enabled in the system
2. A TFO SYN with an invalid TFO cookie matches a listen socket that has TFO enabled
3. The current t_tfo_pending count on that socket is <= so_qlimit / 2

The other way is...

1. TFO enabled
2. t_tfo_pending count <= so_qlimit / 2
3. SYN without a TFO option, followed by a SYN with a valid TFO cookie and the same IPs and port numbers

In D8218#170606, @pkelsey wrote:

See line-specific comments in the patch.

I don't see in-line comments. Perhaps you can resubmit them?

There is still a path that leaks when mac_syncache_init() fails.

I can only identify two circumstances where the t_tfo_pending counter on a listen socket will be incremented without a corresponding decrement ever occurring.

In D7701#159878, @jhb wrote:

This looks correct though I'd be surprised if any code actually ran into it. (Or at least, if kthread_add() is failing your system is probably in trouble already.)

Absent any issues raised, I am going to commit this sometime in the next 24-48 hours.

Fixed issue with discarding TFO ACKs in tcp_do_segment() and fixed issue with snd_una not being properly advanced when TFO connections transition to ESTABLISHED, also in tcp_do_segment(). Also some minor cleanups (comments, whitespace, etc).

File contents for tcp_fastopen.[ch] were missing from the initial diff.

I don't think we should be taking any

We shouldn't be taking any action at all based on a NEEDFRAG message that suggests (or from which we deduce) a new mtu that is the same or larger than the current one. I think the clearest expression of this idea is to only call tcp_mtudisc() from tcp_ctlinput() when the new mtu could decrease tp->t_maxseg (and remove the comment that tcp_mtudisc() 'does the right thing').

Moved </entry> to the end of the </screen> line in the last edit.

Adjusted markup for team approval example per wblock.

It's been two weeks with no further input. I just pinged rstone directly with a last-call. If there are no further objections in the next 8 hours or so, I plan to commit this as-is.

In D3060#60525, @hiren wrote:

https://www.ietf.org/rfc/rfc1323.txt mentions:

The Timestamp Echo Reply field (TSecr) is only valid if the ACK
bit is set in the TCP header; if it is valid, it echos a times-
tamp value that was sent by the remote TCP in the TSval field
of a Timestamps option.  When TSecr is not valid, its value
must be zero.

Which I brought up to Patrick but then he mentioned that while following this and always initializing the tsecr field early in tcpopt processing would be the correct thing to do but the code is already established elsewhere to 1) check the option flag for the timestamp option and then 2) check if the value is not zero.

And I agree that because of that reasoning, the proposed fix seems sufficient to me.

Also adding network so someone else can also review this.

In D3007#59268, @wblock wrote:

Are the local changes FreeBSD-specific? To put it another way, can they be submitted upstream to avoid being lost on the next import? The man page changes look that way, at least.

In D2987#59000, @kib wrote:

This is probably fine.

But, from the description of the sysctlmemlock, it seems that the lock must be owned whenever sysctl_wire_old_buffer() is called, am I right ? If yes, I think an assertion that the lock is owned, should be added to the wire_old_buffer().

In D2922#57500, @erj wrote:

In D2922#57481, @pkelsey wrote:

In D2922#57477, @erj wrote:

Everything but the change in ixgbe_vf.c looks good to me.

It looks like the PF driver needs to not set CTS when it acks the reset request, instead of the VF driver ignoring the flag.

So ixgbe_vf_reset_msg() in if_ix.c needs to change instead.

It certainly wasn't clear to me what the implementation intent was with CTS flag, so I made this change in what appeared to be the most consistent way given the existing code. In this case, ixgbe_set_rar_vf(), ixgbe_set_uc_addr_vf(), and ixgbev_get_queues() served as the reference for what the VF side of things was doing before checking flags in the response header. Considering your requested change to the patch, would those also be changed under the same reasoning? Also, in if_ix.c, ixgbe_vf_get_queues() is setting IXGBE_VT_MSGTYPE_CTS in its response - should that also be eliminated as the receiver of that response is just masking it off?

My reasoning was "do it because it'll match the Linux PF's behavior" and not "I don't like the way you did it." AFAICT, the Linux PF doesn't send CTS on a VF reset request ACK because they don't think it's necessary. The VF is marked as being clear to send in their PF after their reset flow, so they might assume the VF would know it's clear to send if it receives a response.

In D2922#57477, @erj wrote:

Everything but the change in ixgbe_vf.c looks good to me.

It looks like the PF driver needs to not set CTS when it acks the reset request, instead of the VF driver ignoring the flag.

So ixgbe_vf_reset_msg() in if_ix.c needs to change instead.