summaryrefslogtreecommitdiff
path: root/crypto/tcrypt.c
diff options
context:
space:
mode:
authorTuong Lien <tuong.t.lien@dektech.com.au>2019-12-10 15:21:04 +0700
committerDavid S. Miller <davem@davemloft.net>2019-12-10 17:45:04 -0800
commitabc9b4e0549b93fdaff56e9532bc49a2d7b04955 (patch)
tree98c0442453090b770be88a53184d3b7e1cac3e94 /crypto/tcrypt.c
parentdca4a17d24ee9d878836ce5eb8dc25be1ffa5729 (diff)
tipc: fix retrans failure due to wrong destination
When a user message is sent, TIPC will check if the socket has faced a congestion at link layer. If that happens, it will make a sleep to wait for the congestion to disappear. This leaves a gap for other users to take over the socket (e.g. multi threads) since the socket is released as well. Also, in case of connectionless (e.g. SOCK_RDM), user is free to send messages to various destinations (e.g. via 'sendto()'), then the socket's preformatted header has to be updated correspondingly prior to the actual payload message building. Unfortunately, the latter action is done before the first action which causes a condition issue that the destination of a certain message can be modified incorrectly in the middle, leading to wrong destination when that message is built. Consequently, when the message is sent to the link layer, it gets stuck there forever because the peer node will simply reject it. After a number of retransmission attempts, the link is eventually taken down and the retransmission failure is reported. This commit fixes the problem by rearranging the order of actions to prevent the race condition from occurring, so the message building is 'atomic' and its header will not be modified by anyone. Fixes: 365ad353c256 ("tipc: reduce risk of user starvation during link congestion") Acked-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'crypto/tcrypt.c')
0 files changed, 0 insertions, 0 deletions