tcp: remove an invalid KASSERT

[tuexen]

Summary

Since TCP endpoints in the TIME-WAIT state are no longer special, allow them to be switched over to the default stack.

Reported by: [e-mail]

[cc]

Looks I am missing the context. Given the fact that the socket is in TCPS_TIME_WAIT while switching to the default stack, was this assert a day one issue that was not test covered before? Or was this panic caused by recent changes?

[tuexen]

In D51090#1166124, @cc wrote:

Looks I am missing the context. Given the fact that the socket is in TCPS_TIME_WAIT while switching to the default stack, was this assert a day one issue that was not test covered before? Or was this panic caused by recent changes?

Before D36398 TCP endpoints in the TIME-WAIT state had a minimal state. This did not include a reference to a TCP function block. Therefore, there was a check in tcp_ctloutput_set(), which made switching the TCP function block in the TIME-WAIT state impossible by an early return with EINVAL. This means that the KASSERT() was correct before D36398. After D36398, the TIME-WAIT state is not special anymore and consequently, the check was removed in D36400. Since D36400 the bug does exist, I think.
The reason it was reported only recently by syzkaller, is that syzkaller often uses only local TCP connections. The following is an example of the test programs:

# https://syzkaller.appspot.com/bug?id=5ac24a3c5711973c287882c9539f095ac817a309
# See https://goo.gl/kgGztJ for information about syzkaller reproducers.
#{"repeat":true,"procs":1,"slowdown":1,"sandbox":"","sandbox_arg":0,"close_fds":false}
r0 = socket(0x2, 0x1, 0x0)
bind$inet(r0, &(0x7f00000001c0)={0x10, 0x2, 0x2}, 0x10)
setsockopt$inet_tcp_TCP_FUNCTION_BLK(r0, 0x6, 0x2000, &(0x7f0000000080)={'rack\x00', 0x6}, 0x24)
connect$inet(r0, &(0x7f0000000400)={0x10, 0x2, 0x2, @loopback}, 0x10)
sendmsg$unix(r0, &(0x7f0000002580)={0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x180}, 0x20104)
setsockopt$inet_tcp_TCP_FUNCTION_BLK(r0, 0x6, 0x2000, &(0x7f0000000380)={'freebsd\x00', 0x1}, 0x24)

I am sure that syzkaller was running these kind of tests in the past, but only since D51069 local endpoints actually enter the TIME-WAIT state and therefore the bug was uncovered.

[cc]

Thanks for the elaboration. Looks good to me now.