From: Xin Long <lucien.xin@xxxxxxxxx> Date: Thu, 11 Aug 2016 20:52:58 +0800 > Now in the end of sctp_outq_flush, sctp calls sctp_packet_transmit > in a loop. The return of current sctp_packet_transmit always covers > the prior one's. If the last call of sctp_packet_transmit return a > success, it may hide the error that returns from the prior call. > > This patch is to fix this by keeping the old error until the new > error returns from sctp_packet_transmit. Did TAHI test against this > fix, no regression is found. > > Signed-off-by: Xin Long <lucien.xin@xxxxxxxxx> This style of error handling is dangerous. The first error can be lost. For example, if sctp_outq_flush_rtx() earlier in this function returns an error, it will be lost if any invocation of the function sctp_packet_transmit() at the end function signals an error. I think you should always preserve the first error that is recorded into 'error'. I also wonder about why sctp_outq_flush_rtx() errors are completely ignored and don't influence the control flow here in any way. -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
