tcp: don't upgrade a lock just for logging

[tuexen]

Summary

When a outgoing packet can not be logged, because only a read lock is held, don't
upgrade the the lock. Upgrading the lock might harm in case a SYN flood is ongoing.

[tuexen]

Improve panic string.

[lstewart]

sys/netinet/tcp_subr.c

2118

I'd suggest deleting We can not log the packet, since we only own the read lock, but a write lock is needed. as it's not very relevant even though true. Someone could read this comment later and wonder why not try the wlock upgrade approach or another method to ensure the log is generated.

What is more relevant and IMO should be captured in this comment block in place of the above sentence is that the 2 cases which pass through this block are considered to be events which are not appropriately associated with the tcpcb/connection, and therefore we are explicitly choosing not to log them.

Minor language/grammar nit:
... CLOSED state or received in a state later then listen is the UDP encapsulation port is unexpected.
->
... CLOSED state, or received in a more advanced state than LISTEN and the UDP encapsulation port does not match.

[tuexen]

Improve comment based on feedback from lstewart@.

[tuexen]

sys/netinet/tcp_subr.c

2118

I kept the statement about the read/write lock and added an explanation, why we don't do the upgrade dance.

I also added that the segments don't need to be logged since we don't consider them belonging to the connection. I also added a note, that the incoming SYN segments are also not logged.

[tuexen]

Small cleanup

[tuexen]

Improve formatting.

[rrs]

Looks like just what we agreed too ;)