[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <af88a027-61ca-44f2-8d93-43d06076e2a6@openvpn.net>
Date: Wed, 4 Dec 2024 22:37:56 +0100
From: Antonio Quartulli <antonio@...nvpn.net>
To: Paolo Abeni <pabeni@...hat.com>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Donald Hunter <donald.hunter@...il.com>,
Shuah Khan <shuah@...nel.org>, sd@...asysnail.net, ryazanov.s.a@...il.com,
Andrew Lunn <andrew@...n.ch>
Cc: Simon Horman <horms@...nel.org>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net-next v12 11/22] ovpn: implement TCP transport
On 04/12/2024 12:15, Antonio Quartulli wrote:
[...]
>>> +static void ovpn_tcp_close(struct sock *sk, long timeout)
>>> +{
>>> + struct ovpn_socket *sock;
>>> +
>>> + rcu_read_lock();
>>> + sock = rcu_dereference_sk_user_data(sk);
>>> +
>>> + strp_stop(&sock->peer->tcp.strp);
>>> + barrier();
>>
>> Again, is not clear to me the role of the above barrier, please
>> document it.
>
> Also taken from espintcp_close(), with the idea to avoid reordering
> during the shut down sequence.
>
> Will add a comment here too.
Actually, after checking this specific barrier(), I realized this is not
needed, because we are doing the socket detach later, after calling the
ovpn_peer_del() (which is different from what is happening in espintcp).
So I'll just drop this barrier here.
Regards,
--
Antonio Quartulli
OpenVPN Inc.
Powered by blists - more mailing lists