<div dir="ltr">Andrey &amp; Pavel -- Thanks for the clarification.  I&#39;ll update the patch and send out for review once it&#39;s ready.<div><br></div><div>Thanks,</div><div>Amey</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 9, 2015 at 1:15 AM, Pavel Emelyanov <span dir="ltr">&lt;<a href="mailto:xemul@parallels.com" target="_blank">xemul@parallels.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 02/06/2015 10:10 PM, Amey Deshpande wrote:<br>
&gt; For an established TCP connection, the send queue is restored in two<br>
&gt; steps: in step (1), we retransmit the data that was sent before but not<br>
&gt; yet acknowledged, and in step (2), we transmit the data that was never<br>
&gt; sent outside before.  The TCP_REPAIR option is disabled before step (2)<br>
&gt; and re-enabled after step (2) (without this patch).<br>
<br>
</span>Yes, as Andrey pointed out this was done deliberately. Otherwise we introduce<br>
delays in send queue processing.<br>
<span class=""><br>
&gt; If the amount of data to be sent in step (2) is large, the TCP_REPAIR<br>
&gt; flag on the socket can remain off for some time (O(milliseconds)).  If a<br>
&gt; listen() is called on another socket bound to the same port during this<br>
&gt; time window, it fails. This is because -- turning TCP_REPAIR off clears<br>
&gt; the SO_REUSEADDR flag on the socket.<br>
&gt;<br>
&gt; There are several possible ways to prevent this problem from happening:<br>
&gt; - The simplest option is to *not* toggle TCP_REPAIR option while<br>
&gt;   restoring the TCP queues.<br>
&gt; - Another way would be to explicitly enable SO_REUSEADDR on the<br>
&gt;   socket after turning TCP_REPAIR off.  This still leaves a small time<br>
&gt;   window, and such race could still occur.<br>
&gt; - A more involved solution would use a mutex per port number, so<br>
&gt;   that a listen() on a port number does not happen while SO_REUSEADDR for<br>
&gt;   another socket on the same port is off.<br>
<br>
</span>I vote for this way. We already have the per-socket inet_port object that<br>
is shared between processes and new lock can be safely put there.<br>
<span class=""><br>
&gt; This patch removes the toggling of TCP_REPAIR option during restoring<br>
&gt; TCP send queues.<br>
&gt;<br>
&gt; Signed-off-by: Amey Deshpande &lt;<a href="mailto:ameyd@google.com">ameyd@google.com</a>&gt;<br>
<br>
</span>Thanks,<br>
Pavel<br>
<br>
<br>
</blockquote></div><br></div>