From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from shards.monkeyblade.net ([184.105.139.130]:33654 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754474AbeD3QK0 (ORCPT ); Mon, 30 Apr 2018 12:10:26 -0400 Date: Mon, 30 Apr 2018 12:10:24 -0400 (EDT) Message-Id: <20180430.121024.1354407786745903932.davem@davemloft.net> To: eric.dumazet@gmail.com Cc: soheil.kdev@gmail.com, netdev@vger.kernel.org, ycheng@google.com, ncardwell@google.com, edumazet@google.com, willemb@google.com, soheil@google.com Subject: Re: [PATCH V2 net-next 1/2] tcp: send in-queue bytes in cmsg upon read From: David Miller In-Reply-To: References: <20180430.115605.1094351453502803017.davem@davemloft.net> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org List-ID: From: Eric Dumazet Date: Mon, 30 Apr 2018 09:01:47 -0700 > TCP sockets are read by a single thread really (or synchronized > threads), or garbage is ensured, regardless of how the kernel > ensures locking while reporting "queue length" Whatever applications "typically do", we should never return garbage, and that is what this code allowing to happen. Everything else in recvmsg() operates on state under the proper socket lock, to ensure consistency. The only reason we are releasing the socket lock first it to make sure the backlog is processed and we have the most update information available. It seems like one is striving for correctness and better accuracy, no? :-) Look, this can be fixed really simply. And if you are worried about unbounded loops if two apps maliciously do recvmsg() in parallel, then don't even loop, just fallback to full socket locking and make the "non-typical" application pay the price: tmp1 = A; tmp2 = B; barrier(); tmp3 = A; if (unlikely(tmp1 != tmp3)) { lock_sock(sk); tmp1 = A; tmp2 = B; release_sock(sk); } I'm seriously not applying the patch as-is, sorry. This issue must be addressed somehow. Thank you.