df7e88f6ca
Prior to this patch, sctp defined TCP_CLOSING as SCTP_SS_CLOSING. TCP_CLOSING is such a special sk state in TCP that inet common codes even exclude it. For instance, inet_accept thinks the accept sk's state never be TCP_CLOSING, or it will give a WARN_ON. TCP works well with that while SCTP may trigger the call trace, as CLOSING state in SCTP has different meaning from TCP. This fix is to change to use TCP_CLOSE_WAIT as SCTP_SS_CLOSING, instead of TCP_CLOSING. Some side-effects could be expected, regardless of not being used before. inet_accept will accept it now. I did all the func_tests in lksctp-tools and ran sctp codnomicon fuzzer tests against this patch, no regression or failure found. Signed-off-by: Xin Long <lucien.xin@gmail.com> Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
||
---|---|---|
.. | ||
acpi | ||
asm-generic | ||
clocksource | ||
crypto | ||
drm | ||
dt-bindings | ||
keys | ||
kvm | ||
linux | ||
math-emu | ||
media | ||
memory | ||
misc | ||
net | ||
pcmcia | ||
ras | ||
rdma | ||
rxrpc | ||
scsi | ||
soc | ||
sound | ||
target | ||
trace | ||
uapi | ||
video | ||
xen | ||
Kbuild |