[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c28365d5-72e3-335b-372e-2a9069898df1@linux.ibm.com>
Date: Tue, 8 Feb 2022 18:13:42 +0100
From: Karsten Graul <kgraul@...ux.ibm.com>
To: "D. Wythe" <alibuda@...ux.alibaba.com>
Cc: kuba@...nel.org, davem@...emloft.net, netdev@...r.kernel.org,
linux-s390@...r.kernel.org, linux-rdma@...r.kernel.org
Subject: Re: [PATCH net-next v5 2/5] net/smc: Limit backlog connections
On 08/02/2022 13:53, D. Wythe wrote:
> From: "D. Wythe" <alibuda@...ux.alibaba.com>
>
> Current implementation does not handling backlog semantics, one
> potential risk is that server will be flooded by infinite amount
> connections, even if client was SMC-incapable.
In this patch you count the number of inflight SMC handshakes as pending and
check them against the defined max_backlog. I really like this improvement.
There is another queue in af_smc.c, the smc accept queue and any new client
socket that completed the handshake process is enqueued there (in smc_accept_enqueue() )
and is waiting to get accepted by the user space application. To apply the correct
semantics here, I think the number of sockets waiting in the smc accept queue
should also be counted as backlog connections, right? I see no limit for this queue
now. What do you think?
Powered by blists - more mailing lists