public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: Gerd Bayer <gbayer@linux.ibm.com>
To: Wen Gu <guwen@linux.alibaba.com>,
	wenjia@linux.ibm.com, jaka@linux.ibm.com, davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, pabeni@redhat.com
Cc: alibuda@linux.alibaba.com, tonylu@linux.alibaba.com,
	linux-s390@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net] net/smc: avoid overwriting when adjusting sock bufsizes
Date: Tue, 04 Jun 2024 18:16:21 +0200	[thread overview]
Message-ID: <cc606c7b6fb53d00d80122b987c94bd7cb385af0.camel@linux.ibm.com> (raw)
In-Reply-To: <20240531085417.43104-1-guwen@linux.alibaba.com>

Hi Wen Gu,

sorry for the late reply, I'm just catching up after a bit of a
vacation.

On Fri, 2024-05-31 at 16:54 +0800, Wen Gu wrote:
> When copying smc settings to clcsock, avoid setting clcsock's
> sk_sndbuf to sysctl_tcp_wmem[1], since this may overwrite the value
> set by tcp_sndbuf_expand() in TCP connection establishment.
> 
> And the other setting sk_{snd|rcv}buf to sysctl value in
> smc_adjust_sock_bufsizes() can also be omitted since the
> initialization of smc sock and clcsock has set sk_{snd|rcv}buf to
> smc.sysctl_{w|r}mem or ipv4_sysctl_tcp_{w|r}mem[1].
> 
> Fixes: 30c3c4a4497c ("net/smc: Use correct buffer sizes when
> switching between TCP and SMC")
> Link:
> https://lore.kernel.org/r/5eaf3858-e7fd-4db8-83e8-3d7a3e0e9ae2@linux.alibaba.com
> Signed-off-by: Wen Gu <guwen@linux.alibaba.com>
> ---
> FYI,
> The detailed motivation and testing can be found in the link above.
> ---
>  net/smc/af_smc.c | 22 ++--------------------
>  1 file changed, 2 insertions(+), 20 deletions(-)
> 
> diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
> index 9389f0cfa374..a35281153067 100644
> --- a/net/smc/af_smc.c
> +++ b/net/smc/af_smc.c
> @@ -459,29 +459,11 @@ static int smc_bind(struct socket *sock, struct
> sockaddr *uaddr,
>  static void smc_adjust_sock_bufsizes(struct sock *nsk, struct sock
> *osk,
>  				     unsigned long mask)
>  {
> -	struct net *nnet = sock_net(nsk);
> -
>  	nsk->sk_userlocks = osk->sk_userlocks;
> -	if (osk->sk_userlocks & SOCK_SNDBUF_LOCK) {
> +	if (osk->sk_userlocks & SOCK_SNDBUF_LOCK)
>  		nsk->sk_sndbuf = osk->sk_sndbuf;
> -	} else {
> -		if (mask == SK_FLAGS_SMC_TO_CLC)
> -			WRITE_ONCE(nsk->sk_sndbuf,
> -				   READ_ONCE(nnet-
> >ipv4.sysctl_tcp_wmem[1]));
> -		else
> -			WRITE_ONCE(nsk->sk_sndbuf,
> -				   2 * READ_ONCE(nnet-
> >smc.sysctl_wmem));
> -	}
> -	if (osk->sk_userlocks & SOCK_RCVBUF_LOCK) {
> +	if (osk->sk_userlocks & SOCK_RCVBUF_LOCK)
>  		nsk->sk_rcvbuf = osk->sk_rcvbuf;
> -	} else {
> -		if (mask == SK_FLAGS_SMC_TO_CLC)
> -			WRITE_ONCE(nsk->sk_rcvbuf,
> -				   READ_ONCE(nnet-
> >ipv4.sysctl_tcp_rmem[1]));
> -		else
> -			WRITE_ONCE(nsk->sk_rcvbuf,
> -				   2 * READ_ONCE(nnet-
> >smc.sysctl_rmem));
> -	}
>  }
>  
>  static void smc_copy_sock_settings(struct sock *nsk, struct sock
> *osk,

As Wenjia already said, we've discussed this a bit.
As I remember, I've added the sections to copy over the sysctl values 
as a "safety measure" when moving between smc/clc sockets - but had the
wrong assumption in mind that e.g. in a fall-back a new TCP handshake
would be done. Apparently, we didn't test the buffer size behavior in
these scenarios enough to notice the "weird" behavior.

So we reviewed your initial report of the oddity per your message in
the link above, too.

We fully agree that if no connection at the SMC level could be
established, you should expect the socket buffersizes be used that had
been established for the TCP connection - regardless if the fallback is
due to the server or the client.

So feel free to add my
Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com>, too.

Thanks,
Gerd

  parent reply	other threads:[~2024-06-04 16:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-31  8:54 [PATCH net] net/smc: avoid overwriting when adjusting sock bufsizes Wen Gu
2024-06-04 14:04 ` Paolo Abeni
2024-06-04 15:10   ` Wenjia Zhang
2024-06-04 16:16 ` Gerd Bayer [this message]
2024-06-05  6:01   ` Wen Gu
2024-06-05  8:50 ` patchwork-bot+netdevbpf
  -- strict thread matches above, loose matches on Subject: below --
2024-06-04 11:13 Wen Gu

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=cc606c7b6fb53d00d80122b987c94bd7cb385af0.camel@linux.ibm.com \
    --to=gbayer@linux.ibm.com \
    --cc=alibuda@linux.alibaba.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=guwen@linux.alibaba.com \
    --cc=jaka@linux.ibm.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=tonylu@linux.alibaba.com \
    --cc=wenjia@linux.ibm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox