ss_send() may attempt to entail data SKBs to inactive or closed socket

[keshonok]

When a request comes, Tempesta chooses a backend server to forward that request to. By the time Tempesta actually starts putting request's SKBs to the socket connected to the backend server (destination socket), that socket may have been closed or be in the process of closing. ss_send() would then attempt to entail SKBs to a socket that is closed or is being closed.

There's no easy solution.

• Certain measures must be taken to not let the kernel completely delete the destination socket structure.
• The destination socket must be checked to ensure that it still belongs to Tempesta. For that it must be locked (sk->sk_callback_lock) around access to sk->sk_user_data (see issue Tempesta hooks and proper use of close(), drop(), failover, and retry() #107). However, as ss_send() runs under the same lock on the source socket, we have the same case of classic deadlock as in issue Possible recursive locking #61.

Also, #114 is related to this issue.

[krizhanovsky]

Backend socket transmission is done after the request scheduling, i.e. the scheduler 'decides' the socket as alive and backend as normally operational, while it's not actually. This is unexpected condition, so Tempesta must return 500 error to client.

[krizhanovsky]

This is quite similar to #114. So consider this tasks as a task for race condition when the server is chosen when it was alive, but it dies which a request is scheduled to the connection of the server. This case is rare, so moved to next release.

[keshonok]

Fixed with a set of patches in #237.