From: David Howells <dhowe...@redhat.com> Date: Tue, 24 Nov 2015 14:41:59 +0000
> Normally, the transmit phase of a client call is implicitly ack'd by the > reception of the first data packet of the response being received. > However, if a security negotiation happens, the transmit phase, if it is > entirely contained in a single packet, may get an ack packet in response > and then may get aborted due to security negotiation failure. > > Because the client has shifted state to RXRPC_CALL_CLIENT_AWAIT_REPLY due > to having transmitted all the data, the code that handles processing of the > received ack packet doesn't note the hard ack the data packet. > > The following abort packet in the case of security negotiation failure then > incurs an assertion failure when it tries to drain the Tx queue because the > hard ack state is out of sync (hard ack means the packets have been > processed and can be discarded by the sender; a soft ack means that the > packets are received but could still be discarded and rerequested by the > receiver). > > To fix this, we should record the hard ack we received for the ack packet. > > The assertion failure looks like: ... > Signed-off-by: David Howells <dhowe...@redhat.com> Applied, thanks David. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
