On 15 Dec 2023, at 16:47, Dai Ngo wrote: > If the client interface is down, or there is a network partition between > the client and server, that prevents the callback request to reach the > client TCP on the server will keep re-transmitting the callback for about > ~9 minutes before giving up and closes the connection. > > If the connection between the client and the server is re-established > before the connection is closed and after the callback timed out (9 secs) > then the re-transmitted callback request will arrive at the client. When > the server receives the reply of the callback, receive_cb_reply prints the > "Got unrecognized reply..." message in the system log since the callback > request was already removed from the server xprt's recv_queue. > > Even though this scenario has no effect on the server operation, a > malicious client can take advantage of this behavior and send thousand > of callback replies with random XIDs to fill up the server's system log. I don't think this is a serious risk. There's plenty of things a malicious client can do besides try to fill up a system log. This particular printk has been an excellent indicator of transport or client issues over the years. Seeing it in the log on a customer systems shaves a lot of time off an initial triage of an issue. Seeing it in my testing environment immediately notifies me of what might be an otherwise hard-to-notice problem. Ben
