All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lu <tonylu@linux.alibaba.com>
To: Karsten Graul <kgraul@linux.ibm.com>
Cc: kuba@kernel.org, davem@davemloft.net, guwen@linux.alibaba.com,
	netdev@vger.kernel.org, linux-s390@vger.kernel.org,
	linux-rdma@vger.kernel.org
Subject: Re: [PATCH RFC net] net/smc: Ensure the active closing peer first closes clcsock
Date: Wed, 24 Nov 2021 19:26:48 +0800	[thread overview]
Message-ID: <YZ4heNX49qcOUnFS@TonyMac-Alibaba> (raw)
In-Reply-To: <1f67548e-cbf6-0dce-82b5-10288a4583bd@linux.ibm.com>

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

      reply	other threads:[~2021-11-24 11:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-16  3:30 [PATCH RFC net] net/smc: Ensure the active closing peer first closes clcsock Tony Lu
2021-11-17 16:19 ` Karsten Graul
2021-11-22 16:47   ` Karsten Graul
2021-11-23  3:03     ` Tony Lu
2021-11-23  9:26 ` Karsten Graul
2021-11-24  8:57   ` Tony Lu
2021-11-24 10:08     ` Karsten Graul
2021-11-24 11:26       ` Tony Lu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YZ4heNX49qcOUnFS@TonyMac-Alibaba \
    --to=tonylu@linux.alibaba.com \
    --cc=davem@davemloft.net \
    --cc=guwen@linux.alibaba.com \
    --cc=kgraul@linux.ibm.com \
    --cc=kuba@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.