On Wed, Nov 24, 2021 at 11:08:23AM +0100, Karsten Graul wrote: > On 24/11/2021 09:57, Tony Lu wrote: > > IMHO, given that, it is better to not ignore smc_close_final(), and move > > kernel_sock_shutdown() to __smc_release(), because smc_shutdown() also > > calls kernel_sock_shutdown() after smc_close_active() and > > smc_close_shutdown_write(), then enters SMC_PEERCLOSEWAIT1. It's no need > > to call it twice with SHUT_WR and SHUT_RDWR. > > Since the idea is to shutdown the socket before the remote peer shutdowns it > first, are you sure that this shutdown in smc_release() is not too late? Hi Graul, Yes, I have tested this idea, it will be too late sometime. I won't fix this issue. > Is it sure that smc_release() is called in time for this processing? > > Maybe its better to keep the shutdown in smc_close_active() and to use an rc1 > just like shown in your proposal, and return either the rc of smc_close_final() > or the rc of kernel_sock_shutdown(). Yep, I am testing this approach in my environment. I am going to keep these return codes and return the available one. > I see the possibility of calling shutdown twice for the clcsocket, but does it > harm enough to give a reason to check it before in smc_shutdown()? I expect TCP > to handle this already. TCP could handle this already, but it doesn't make much sense to call it twice. When call smc_shutdown(), we can check sk_shutdown before call kernel_sock_shutdown(), so that it can slightly speed up the release process. I will send this soon, thanks for your advice. Tony Lu
