From patchwork Wed Apr 25 18:33:08 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yuchung Cheng X-Patchwork-Id: 904664 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.b="N05SCv5d"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 40WTNK4WjZz9s1P for ; Thu, 26 Apr 2018 04:33:21 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755846AbeDYSdS (ORCPT ); Wed, 25 Apr 2018 14:33:18 -0400 Received: from mail-pg0-f65.google.com ([74.125.83.65]:46629 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752902AbeDYSdR (ORCPT ); Wed, 25 Apr 2018 14:33:17 -0400 Received: by mail-pg0-f65.google.com with SMTP id z4so1020890pgu.13 for ; Wed, 25 Apr 2018 11:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=jiIlTknq04ub8/jgOzcrn1dTdfQ7Uzu5RbUmT+GGkBM=; b=N05SCv5dMlftWVaaVTK1mINtX69//8R3JNRXNLXmqOSQu9PbaaDAU7jGi0HtVvgXy4 ahuEUnmSmfrR8yFsqZIP+SpUQb/8ctA/sNjae4byaqM0ARRYbUwIRDPF5BYbBhAQSBoQ 86rws1I1435U+7HgjDfYcpLTHUPkyom1H95uvQnk53EzMjcHLO5f5YhBTpN3dNm8ENoE 0LOwBAxPegp43z1dJDbMRKsogb0ArB6wbaeF1/pfgx/RRMNYeFfwilR3w7lS2yxi0eQQ 41xFbOTQMQ31SWXVa37jokUNNoQ4Fgew4h7JkcDb1ey/bbIrp/GsU+s7UDs4MOX2Jg1i m3yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=jiIlTknq04ub8/jgOzcrn1dTdfQ7Uzu5RbUmT+GGkBM=; b=O5+qoW0mvKxD0P8O3QVK5GsZvhO+7qMScslfCPRJOsHH/J/OuJrIOCOGF5lgc+LFry ptOf7DcxJKNhwd7WCgjTvU2iBhKznVi0ljxa3+n6yiN/FGOs8UIKxdKB5/byiyHAPL/O zsjR2A6HhAgR4LZ3Ym8zVkytyy3t/tevqiuqOfaC4ZvSgtY872gyesJOrkTJ0CzTnKzW IN9+oMO8BI3tuMInlOdEqFO8Tnb0m/QZK6RqDK3o11EYjosOq5CGsug3AmvBG3Edi2Cr B6GkH9sBGxz3BD3jkUgaf+JROqMLu6iVGhc6FKFPnMed35am0mo+CmvlzcBbW/nPxgW/ ApQw== X-Gm-Message-State: ALQs6tAcjtexZaMOORwreIYif13oaeGlgcHNDDeKZ/SPNEgt1ysMHpkk y/FFbR3l/BcuAQHYjaKOVxquLA== X-Google-Smtp-Source: AB8JxZqG9PKkTeNO7ySTeIrQ+00lnCKVPOJiguIqfNCWxVIxDSqwwNP/z23UFYBXuL5F+t2k7CIDGQ== X-Received: by 10.101.99.73 with SMTP id p9mr4114636pgv.111.1524681196175; Wed, 25 Apr 2018 11:33:16 -0700 (PDT) Received: from ycheng2.svl.corp.google.com ([2620:15c:2c4:201:d660:6c0b:8a4f:4c77]) by smtp.gmail.com with ESMTPSA id t80sm30570975pgb.36.2018.04.25.11.33.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Apr 2018 11:33:15 -0700 (PDT) From: Yuchung Cheng To: davem@davemloft.net Cc: netdev@vger.kernel.org, edumazet@google.com, ncardwell@google.com, Yuchung Cheng Subject: [PATCH net] tcp: ignore Fast Open on repair mode Date: Wed, 25 Apr 2018 11:33:08 -0700 Message-Id: <20180425183308.70232-1-ycheng@google.com> X-Mailer: git-send-email 2.17.0.441.gb46fe60e1d-goog Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org The TCP repair sequence of operation is to first set the socket in repair mode, then inject the TCP stats into the socket with repair socket options, then call connect() to re-activate the socket. The connect syscall simply returns and set state to ESTABLISHED mode. As a result Fast Open is meaningless for TCP repair. However allowing sendto() system call with MSG_FASTOPEN flag half-way during the repair operation could unexpectedly cause data to be sent, before the operation finishes changing the internal TCP stats (e.g. MSS). This in turn triggers TCP warnings on inconsistent packet accounting. The fix is to simply disallow Fast Open operation once the socket is in the repair mode. Reported-by: syzbot Signed-off-by: Yuchung Cheng Reviewed-by: Neal Cardwell Reviewed-by: Eric Dumazet --- net/ipv4/tcp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c index 9ce1c726185e..4b18ad41d4df 100644 --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -1204,7 +1204,8 @@ int tcp_sendmsg_locked(struct sock *sk, struct msghdr *msg, size_t size) uarg->zerocopy = 0; } - if (unlikely(flags & MSG_FASTOPEN || inet_sk(sk)->defer_connect)) { + if (unlikely(flags & MSG_FASTOPEN || inet_sk(sk)->defer_connect) && + !tp->repair) { err = tcp_sendmsg_fastopen(sk, msg, &copied_syn, size); if (err == -EINPROGRESS && copied_syn > 0) goto out;