There's a race possible where set_valid_greeting() runs just as
another greeting reply sits on the resend_queue from a handshake:
1. server_greeting() calls scoutfs_net_response() to queue the
server's greeting reply on send_queue and kicks send_work.
2. server_greeting() falls through to scoutfs_net_server_greeting()
which calls set_valid_greeting() under conn->lock.
3. If send_work already ran between steps 1 and 2 it moved the
reply onto resend_queue.
4. set_valid_greeting() splices resend_queue back into send_queue,
re-queueing the greeting reply for a second send on the same
socket.
The receiver treats a duplicate greeting as fatal: the receive path
invalid_message check on the saw_greeting flag tears the connection
down silently. The client never sees a normal disconnect, just a
stalled connection, and the server only notices once the 30s
recovery timeout fires and fences the client.
Fix by walking resend_queue in set_valid_greeting() and dropping any
queued greeting before splicing them in. Dropping them should be safe
and mimics what scoutfs_net_shutdown_worker() does.
Signed-off-by: Auke Kok <auke.kok@versity.com>
Auke Kok
4dc694834e