Bug #1775

Bug #1631: kernel panic in tcp_input_data

1631's fix missed the case of data on the handshake's ACK

Added by Dan McDonald over 6 years ago. Updated over 6 years ago.

Status:ResolvedStart date:2011-11-14
Priority:UrgentDue date:
Assignee:Dan McDonald% Done:


Target version:-
Difficulty:Medium Tags:diagnosed


Consider this exchange:

a->b  SYN
b->a  SYN/ACK
a->b  ACK+data(PSH)

this is legal, and the data should be delivered, but after 1631 the data will drop. In DEBUG kernels, it will cause an assertion failure in tcp_dummy_recv().

What happens is that with 1631, "sockupcalls" is initialized early on, which is good when conn_upcalls is NULL (and can be replaced), but upon receipt of the third ACK, conn_upcalls is upgraded from NULL to non-NULL. If there is data on that ACK, "sockupcalls" is still NULL in this case, and the data is sent to tcp_dummy_recv.


#1 Updated by Gordon Ross over 6 years ago

  • Status changed from New to Resolved
changeset:   13521:901a793ed0dd
user:        Dan McDonald <danmcd@nexenta.com>
date:        Mon Nov 14 19:23:57 2011 -0500
    1775 1631's fix missed the case of data on the handshake's ACK
    Reviewed by: Michael Speer <michael.speer@pluribusnetworks.com>
    Reviewed by: Garrett D'Amore <Garrett.DAmore@nexenta.com>
    Reviewed by: Gordon Ross <gwr@nexenta.com>
    Approved by: Gordon Ross <gwr@nexenta.com>

Also available in: Atom