netdev - Re: [PATCH RFC net] net/smc: Ensure the active closing peer first closes clcsock

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: <YZxaHVHTg5cxnarY@TonyMac-Alibaba>
Date:   Tue, 23 Nov 2021 11:03:57 +0800
From:   Tony Lu <tonylu@...ux.alibaba.com>
To:     Karsten Graul <kgraul@...ux.ibm.com>
Cc:     kuba@...nel.org, davem@...emloft.net, guwen@...ux.alibaba.com,
        netdev@...r.kernel.org, linux-s390@...r.kernel.org,
        linux-rdma@...r.kernel.org
Subject: Re: [PATCH RFC net] net/smc: Ensure the active closing peer first
 closes clcsock

On Mon, Nov 22, 2021 at 05:47:43PM +0100, Karsten Graul wrote:
> On 17/11/2021 17:19, Karsten Graul wrote:
> > On 16/11/2021 04:30, Tony Lu wrote:
> >> We found an issue when replacing TCP with SMC. When the actively closed
> >> peer called close() in userspace, the clcsock of peer doesn't enter TCP
> >> active close progress, but the passive closed peer close it first, and
> >> enters TIME_WAIT state. It means the behavior doesn't match what we
> >> expected. After reading RFC7609, there is no clear description of the
> >> order in which we close clcsock during close progress.
> > 
> > Thanks for your detailed description, it helped me to understand the problem.
> > Your point is that SMC sockets should show the same behavior as TCP sockets
> > in this situation: the side that actively closed the socket should get into
> > TIME_WAIT state, and not the passive side. I agree with this.
> > Your idea to fix it looks like a good solution for me. But I need to do more
> > testing to make sure that other SMC implementations (not Linux) work as
> > expected with this change. For example, Linux does not actively monitor the 
> > clcsocket state, but if another implementation would do this it could happen
> > that the SMC socket is closed already when the clcsocket shutdown arrives, and
> > pending data transfers are aborted.
> > 
> > I will respond to your RFC when I finished my testing.
> > 
> > Thank you.
> > 
> 
> Testing and discussions are finished, the patch looks good.
> Can you please send your change as a patch to the mailing list?

Thanks for your advice and testing. I will send it soon.

Cheers,
Tony Lu