netdev - Re: [PATCH net 1/2] RDS:TCP: Synchronize rds_tcp_accept_one with rds_send_xmit when resetting t

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ce6dfb1a-c129-b49c-1dd5-7503b673ff0b@oracle.com>
Date:	Mon, 2 May 2016 11:05:39 -0700
From:	Santosh Shilimkar <santosh.shilimkar@...cle.com>
To:	Sowmini Varadhan <sowmini.varadhan@...cle.com>
Cc:	netdev@...r.kernel.org, rds-devel@....oracle.com,
	davem@...emloft.net
Subject: Re: [PATCH net 1/2] RDS:TCP: Synchronize rds_tcp_accept_one with
 rds_send_xmit when resetting t_sock

On 5/2/2016 9:37 AM, Sowmini Varadhan wrote:
> On (05/02/16 09:20), Santosh Shilimkar wrote:
>>> 	rds_conn_transition(conn, RDS_CONN_DOWN, RDS_CONN_CONNECTING);
>>> +	if (rs_tcp->t_sock) {
>>> +		/* Need to resolve a duelling SYN between peers.
>>> +		 * We have an outstanding SYN to this peer, which may
>>> +		 * potentially have transitioned to the RDS_CONN_UP state,
>>> +		 * so we must quiesce any send threads before resetting
>>> +		 * c_transport_data.
>>> +		 */
>>> +		wait_event(conn->c_waitq,
>>> +			   !test_bit(RDS_IN_XMIT, &conn->c_flags));
>> Would it be good to check the return value of rds_conn_transition()
>> since if CONN is already UP above will fail and then send message
>> might again race and we will let message through even though passive
>> hasn't finished its connection.
>
> no, that was the original issue that I was running into, which needed
> commit 241b2719 - prior to that commit, if the conn was already UP,
> we'd end up doing a rds_conn_drop on a good connection, and both sides
> would end up in a pair of infinite 3WH loops. Even if we dont do
> a rds_conn_drop on the UP connection, we've just (before
> rds_tcp_accept_one) sent out a syn-ack on the incoming syn, and now
> need to RST that syn-ac.  The other side is going to receive the rst,
> and get confused about what to clean up (since there's already an UP
> connection going on).
>
> In short, when there is a duel, it's cleanest to have a deterministic
> arbitration- both sides use the numeric value of saddr and faddr to
> figure out which side is active, which side is passive. (Thus the
> basis on the BGP router-id based model for 241b2719)
>
> FWIW, much of this is actually a corner case-  in practice, its not
> frequent to have syns crossing each other at "almost the same time".
>
Sounds good. Thanks for expanding it. Patch looks good to me.

Acked-by: Santosh Shilimkar <santosh.shilimkar@...cle.com>