Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp3083790pxb; Mon, 9 Nov 2020 01:58:36 -0800 (PST) X-Google-Smtp-Source: ABdhPJxx5vgmK6743TO5HuGyt/NuXzyHUBaCqPsJvIZGliImc+z4+ZyPxPv2k5uAWgchdfK6bUwu X-Received: by 2002:a17:906:8c6:: with SMTP id o6mr13590121eje.230.1604915915869; Mon, 09 Nov 2020 01:58:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604915915; cv=none; d=google.com; s=arc-20160816; b=iIr6/QtFxcx2UUUsKD+UdIHQKvwrkJq76dRGYQ5TRq7pgoXfMLw1IDgIeUAlgmcZhN Gw/6N6CpqzIf3jphQnEIXODI1GP5Uj5zF4uaaqjZq1csUqttcnFm2EwVuJcNcp4DktIq ehO2uMtfCa32U3c40NLgL1AyOdKKZ5LeDxVhADwfRVSBrSyxY/e1CCLdfu7rBrHo6yGg a2CAyzI21QrvgObHFBAgRN2egrNnkgLfsZZ1rJlJwOQHMAZnw05FTuK7iE6hiPmXMZXD rkLEB0qCUfLjp7BM6AITM8AokENyulN7ewmqnCjR5G7Fy1Y3AP4k6f6BVnKet9kBEmXN d+ug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Reyf2LTkl/nZmDymc/C7yhdYxGBOvgpjf15ijhHXrXk=; b=vtm3zozbDsFis63bIO1BvpKEqujPq0FCf5WzRETOe/qjMnlnNKCpxENOO5Gt4CF6ZZ e6mRNFheM2co1Ul+LYXgxIthJsek+nMmjjQQAgD/rTbIP2n/7bDfuSJgkPPAisHcTmB8 hJ2ZN7baPv6R/Q3dYWGjNVb6iuwxYOtfImXsoThCwxr+a4+3u+LOzKRdWDQCXpplM2kT xltUvX1Y2TVNaDtcQEszr6g/EntovdBHxsDkKsYKtho9csKYaePp6SbF2upXWiPeznyV yf3sLwqEgothtzI26cT0RYvNXZiesANT3bx9U/OjcQn9rQNO1i1rXFUj3WL9As6UuKk4 Ca3w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=h6lPXGm5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w13si6451384ejz.76.2020.11.09.01.58.11; Mon, 09 Nov 2020 01:58:35 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=h6lPXGm5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729037AbgKIJ4p (ORCPT + 99 others); Mon, 9 Nov 2020 04:56:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48426 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727791AbgKIJ4p (ORCPT ); Mon, 9 Nov 2020 04:56:45 -0500 Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6F908C0613D3 for ; Mon, 9 Nov 2020 01:56:45 -0800 (PST) Received: by mail-il1-x143.google.com with SMTP id n5so7699837ile.7 for ; Mon, 09 Nov 2020 01:56:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Reyf2LTkl/nZmDymc/C7yhdYxGBOvgpjf15ijhHXrXk=; b=h6lPXGm5aOnj3YuFHHOqJ54jB/gd4poG1bgWPgpyvt1+NfFOh6lcPqHeMzjQ5mrY/R roMcD+FaCTwRBOyX59DBpv/ueZZhi20x3WwIXkAmCZDcbSUt2nX3tjhN3kg47VnpDhdc jJgmoPlA3KUlxJ5pH0Jg9ger371DV+iH1uMkxd/s8gjxHsYws9GbIN9iiWUgvyrhqbNZ yuuzXK3xJOoiBcEXuWxdzums+aOvjz8Za2NJQ2bOGm3QMVMFtDAxvhZl7o+oZ2a5vNSB AQdesuNpbCDL2C7tRxfUBr7v+gUe2SiNFMiXJeyaMvZlE7qHRRd3pp7t0BZocUDYeU0t bhmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Reyf2LTkl/nZmDymc/C7yhdYxGBOvgpjf15ijhHXrXk=; b=Lt25uvdmD5JytNUV2micmwKj3lat1SwkF5IyUuBUEJBg5bByuSy5B1EFpV77rx1YRD TJ89qqcA1xQehg8Xggl7jn/BYCMbYZosBhXjX8K9Mmi1OauYJcYggk21VziZM1Y0nbxt txR9W06xjmsT+t3pAPLD0+xmldLaMZATGUhj6eGgQicYe//kSn2ZrHxixwVVjetdG7ke SazdrV0fWjzBIBggyelwvdZaHaNghq2b4jeQQ3Amsm1mOfSju36pLn1sarN52QukS/8i f1VI0O9u5FdDR/LducAzZX36LyftU81zrLqz38r7zYllgSiotXqNi0vDG1IKFb6Wyiqq 9CDw== X-Gm-Message-State: AOAM532bVblfC3YlqlB/Z0KDPt0arx1l+SBLwRUaePmMCjxOX/TiFl5Y Iij7WlvPHiHrfEuwXxSzZ9xY1ptU5VEjgfsmsqakLA== X-Received: by 2002:a92:6f11:: with SMTP id k17mr9516216ilc.69.1604915804564; Mon, 09 Nov 2020 01:56:44 -0800 (PST) MIME-Version: 1.0 References: <1604913614-19432-1-git-send-email-wenan.mao@linux.alibaba.com> <1604914417-24578-1-git-send-email-wenan.mao@linux.alibaba.com> In-Reply-To: <1604914417-24578-1-git-send-email-wenan.mao@linux.alibaba.com> From: Eric Dumazet Date: Mon, 9 Nov 2020 10:56:33 +0100 Message-ID: Subject: Re: [PATCH net v2] net: Update window_clamp if SOCK_RCVBUF is set To: Mao Wenan Cc: David Miller , Alexey Kuznetsov , Hideaki YOSHIFUJI , Jakub Kicinski , netdev , LKML , kernel-janitors@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 9, 2020 at 10:33 AM Mao Wenan wrote: > > When net.ipv4.tcp_syncookies=1 and syn flood is happened, > cookie_v4_check or cookie_v6_check tries to redo what > tcp_v4_send_synack or tcp_v6_send_synack did, > rsk_window_clamp will be changed if SOCK_RCVBUF is set, > which will make rcv_wscale is different, the client > still operates with initial window scale and can overshot > granted window, the client use the initial scale but local > server use new scale to advertise window value, and session > work abnormally. What is not working exactly ? Sending a 'big wscale' should not really matter, unless perhaps there is a buggy stack at the remote end ? > > Signed-off-by: Mao Wenan > --- > v2: fix for ipv6. > net/ipv4/syncookies.c | 4 ++++ > net/ipv6/syncookies.c | 5 +++++ > 2 files changed, 9 insertions(+) > > diff --git a/net/ipv4/syncookies.c b/net/ipv4/syncookies.c > index 6ac473b..57ce317 100644 > --- a/net/ipv4/syncookies.c > +++ b/net/ipv4/syncookies.c > @@ -427,6 +427,10 @@ struct sock *cookie_v4_check(struct sock *sk, struct sk_buff *skb) > > /* Try to redo what tcp_v4_send_synack did. */ > req->rsk_window_clamp = tp->window_clamp ? :dst_metric(&rt->dst, RTAX_WINDOW); > + /* limit the window selection if the user enforce a smaller rx buffer */ > + if (sk->sk_userlocks & SOCK_RCVBUF_LOCK && > + (req->rsk_window_clamp > tcp_full_space(sk) || req->rsk_window_clamp == 0)) > + req->rsk_window_clamp = tcp_full_space(sk); This seems not needed to me. We call tcp_select_initial_window() with tcp_full_space(sk) passed as the 2nd parameter. tcp_full_space(sk) will then apply : space = min(*window_clamp, space); Please cook a packetdrill test to demonstrate what you are seeing ?