Received-SPF: pass (google.com: domain of linux-kernel+bounces-201052-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <cc606c7b6fb53d00d80122b987c94bd7cb385af0.camel@linux.ibm.com>
Subject: Re: [PATCH net] net/smc: avoid overwriting when adjusting sock
 bufsizes
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
Date: Tue, 04 Jun 2024 18:16:21 +0200
In-Reply-To: <20240531085417.43104-1-guwen@linux.alibaba.com>
References: <20240531085417.43104-1-guwen@linux.alibaba.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.52.1 (3.52.1-1.fc40app1) 
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
MIME-Version: 1.0

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.
>=20
> 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].
>=20
> 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.alib=
aba.com
> Signed-off-by: Wen Gu <guwen@linux.alibaba.com>
> ---
> FYI,
> The detailed motivation and testing can be found in the link above.
> ---
> =C2=A0net/smc/af_smc.c | 22 ++--------------------
> =C2=A01 file changed, 2 insertions(+), 20 deletions(-)
>=20
> 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,
> =C2=A0static void smc_adjust_sock_bufsizes(struct sock *nsk, struct sock
> *osk,
> =C2=A0				=C2=A0=C2=A0=C2=A0=C2=A0 unsigned long mask)
> =C2=A0{
> -	struct net *nnet =3D sock_net(nsk);
> -
> =C2=A0	nsk->sk_userlocks =3D osk->sk_userlocks;
> -	if (osk->sk_userlocks & SOCK_SNDBUF_LOCK) {
> +	if (osk->sk_userlocks & SOCK_SNDBUF_LOCK)
> =C2=A0		nsk->sk_sndbuf =3D osk->sk_sndbuf;
> -	} else {
> -		if (mask =3D=3D SK_FLAGS_SMC_TO_CLC)
> -			WRITE_ONCE(nsk->sk_sndbuf,
> -				=C2=A0=C2=A0 READ_ONCE(nnet-
> >ipv4.sysctl_tcp_wmem[1]));
> -		else
> -			WRITE_ONCE(nsk->sk_sndbuf,
> -				=C2=A0=C2=A0 2 * READ_ONCE(nnet-
> >smc.sysctl_wmem));
> -	}
> -	if (osk->sk_userlocks & SOCK_RCVBUF_LOCK) {
> +	if (osk->sk_userlocks & SOCK_RCVBUF_LOCK)
> =C2=A0		nsk->sk_rcvbuf =3D osk->sk_rcvbuf;
> -	} else {
> -		if (mask =3D=3D SK_FLAGS_SMC_TO_CLC)
> -			WRITE_ONCE(nsk->sk_rcvbuf,
> -				=C2=A0=C2=A0 READ_ONCE(nnet-
> >ipv4.sysctl_tcp_rmem[1]));
> -		else
> -			WRITE_ONCE(nsk->sk_rcvbuf,
> -				=C2=A0=C2=A0 2 * READ_ONCE(nnet-
> >smc.sysctl_rmem));
> -	}
> =C2=A0}
> =C2=A0
> =C2=A0static 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=20
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