netdev - Re: [PATCH net-next v2] net/smc: Reduce overflow of smc clcsock listen queue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220105085748.GD31579@linux.alibaba.com>
Date:   Wed, 5 Jan 2022 16:57:48 +0800
From:   "dust.li" <dust.li@...ux.alibaba.com>
To:     "D. Wythe" <alibuda@...ux.alibaba.com>,
        Karsten Graul <kgraul@...ux.ibm.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 v2] net/smc: Reduce overflow of smc clcsock
 listen queue

On Wed, Jan 05, 2022 at 12:40:49PM +0800, D. Wythe wrote:
>Hi, 
>
>Since we are trying to use the backlog parameter to limit smc dangling
>connections, it's seems there's no difference from increasing the
>backlog parameter for the TCP listen socket, user space Application can
>simply avoid the 10K connections problem through that.
>
>If so, this patch looks redundant to me. Look forward to your advise.

I think increase backlog in the userspace application is not a good idea.

AFAIU, SMC tries to behave the same like TCP in the socket layer, asking
the APP to increase the backlog breaks this principle.

In the TCP case, the backlog usually don't get overflow if the APP calls
accept() fast enough.
For SMC, it should also accept() fast enough to make sure the backlog of
the CLC socket won't overflow. But it didn't because smc_hs_wq is busy
hence TCP dropped the SYN. From the APP's perspective of view, he is fast
enough, but the kernel didn't give him the chance. I think this behaves
different from TCP.

I'm thinking maybe we can actively fall back to TCP in this case ? Not
sure if this is a good idea.