From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E46F9C388F7 for ; Mon, 9 Nov 2020 11:41:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 89751206B6 for ; Mon, 9 Nov 2020 11:41:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="VeNw+S3F" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729749AbgKILlc (ORCPT ); Mon, 9 Nov 2020 06:41:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37026 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729651AbgKILlb (ORCPT ); Mon, 9 Nov 2020 06:41:31 -0500 Received: from mail-il1-x142.google.com (mail-il1-x142.google.com [IPv6:2607:f8b0:4864:20::142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6B8F5C0613D3 for ; Mon, 9 Nov 2020 03:41:31 -0800 (PST) Received: by mail-il1-x142.google.com with SMTP id x7so7982450ili.5 for ; Mon, 09 Nov 2020 03:41:31 -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:content-transfer-encoding; bh=rvy9/WkLCxYxtHuDnEwzo7NVYvNBUGnMi/E3lzNTZiU=; b=VeNw+S3Fb2nmjMIz7GerJ9k7CYcEDXKZqMHEblY+L/1ubVSAfK5ZmtOeuQWyYpqL9C ivnLJt/qAnNlHbPQQI+uut27ATNnIDTrW7XjmrnafVZo8YmGh6b5+EFF3DzhuMxFd/um kTvKAc68vHorDClk80q2S2+wMU3DYKxUBPDun3p3J4vPYZecAn2YUs+hAVDhhhg/n2yY bXwn4gcKz8IFGpm+T4t+HlHYtSXj8JwleBAyEWlQdXQbTT7JQKHmH0usI3KqMUI90Gu3 b9yUCAw0IakLsMoi+h8bGyMw9YwGW1vTHxQwgGtIpv9iGqDmkzaphSAhaIRcni9sGBek j2xg== 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:content-transfer-encoding; bh=rvy9/WkLCxYxtHuDnEwzo7NVYvNBUGnMi/E3lzNTZiU=; b=pfIT4xz0b9jBm9/yQX7DPIqDsF//tPDJTpJlxYERIjZ710W8x8m8xv7sSYYaCgQZf8 d90buNDuYHVbB4oDHDgIDqhkc9440meAMS7HJDLBZZRAoVm89Pc09CjYnTwt7MhAmfnH XpJOeSCME4ujywAQKMwDZ0QdOMZTy7jL5/vmu/OCqxaD6gZFv3gdEgVWv3sR4Znktb8a XelDNoCTkgaZnDcu7Ts0+Ijpgs/GyJeGHNFZh2tb6eT1bwBMCogEOpzilCciA7NDqLEh pXsELz4Xvp9Ou0cK7wNDFKSygsqWkxG9pOlQ/lFup2sjbph8vphmxux+g2e1tdHLvmKt WjgA== X-Gm-Message-State: AOAM532sDqFJygoFuqxN0O1SPbZI33dn4fw8fxY66qC+jynLhy7Q2kVr YCru0QEuLQfR7TRbhCSohb9MhpTsSeMGG6pDjQNE/Q== X-Google-Smtp-Source: ABdhPJz3qLOUE/G75fCctA62RI4+6Fx4vrvuNy0j+jzQhoNBnx7H5kZbMbH0YPhIb+t3GtjiNwt6TV6dGxYa1LAkSJo= X-Received: by 2002:a92:7f08:: with SMTP id a8mr9095512ild.216.1604922090454; Mon, 09 Nov 2020 03:41:30 -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> <3b92167c-201c-e85d-822d-06f0c9ac508c@linux.alibaba.com> In-Reply-To: From: Eric Dumazet Date: Mon, 9 Nov 2020 12:41:19 +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" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Packetdrill test would be : // Force syncookies `sysctl -q net.ipv4.tcp_syncookies=3D2` 0 socket(..., SOCK_STREAM, IPPROTO_TCP) =3D 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) =3D 0 +0 setsockopt(3, SOL_SOCKET, SO_RCVBUF, [2048], 4) =3D 0 +0 bind(3, ..., ...) =3D 0 +0 listen(3, 1) =3D 0 +0 < S 0:0(0) win 32792 +0 > S. 0:0(0) ack 1 +.1 < . 1:1(0) ack 1 win 1024 +0 accept(3, ..., ...) =3D 4 +0 %{ assert tcpi_snd_wscale =3D=3D 0, tcpi_snd_wscale }% On Mon, Nov 9, 2020 at 12:02 PM Eric Dumazet wrote: > > On Mon, Nov 9, 2020 at 11:12 AM Mao Wenan w= rote: > > > > > > > > =E5=9C=A8 2020/11/9 =E4=B8=8B=E5=8D=885:56, Eric Dumazet =E5=86=99=E9= =81=93: > > > On Mon, Nov 9, 2020 at 10:33 AM Mao Wenan wrote: > > >> > > >> When net.ipv4.tcp_syncookies=3D1 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 ? > > 1)in tcp_v4_send_synack, if SO_RCVBUF is set and > > tcp_full_space(sk)=3D65535, pass req->rsk_window_clamp=3D65535 to > > tcp_select_initial_window, rcv_wscale will be zero, and send to client, > > the client consider wscale is 0; > > 2)when ack is back from client, if there is no this patch, > > req->rsk_window_clamp is 0, and pass to tcp_select_initial_window, > > wscale will be 7, this new rcv_wscale is no way to advertise to client. > > 3)if server send rcv_wind to client with window=3D63, it consider the r= eal > > window is 63*2^7=3D8064, but client consider the server window is only > > 63*2^0=3D63, it can't send big packet to server, and the send-q of clie= nt > > is full. > > > > I see, please change your patches so that tcp_full_space() is used _once_ > > listener sk_rcvbuf can change under us. > > I really have no idea how window can be set to 63, so please send us > the packetdrill test once you have it. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Date: Mon, 09 Nov 2020 11:41:19 +0000 Subject: Re: [PATCH net v2] net: Update window_clamp if SOCK_RCVBUF is set Message-Id: List-Id: References: <1604913614-19432-1-git-send-email-wenan.mao@linux.alibaba.com> <1604914417-24578-1-git-send-email-wenan.mao@linux.alibaba.com> <3b92167c-201c-e85d-822d-06f0c9ac508c@linux.alibaba.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: Mao Wenan Cc: David Miller , Alexey Kuznetsov , Hideaki YOSHIFUJI , Jakub Kicinski , netdev , LKML , kernel-janitors@vger.kernel.org Packetdrill test would be : // Force syncookies `sysctl -q net.ipv4.tcp_syncookies=2` 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 setsockopt(3, SOL_SOCKET, SO_RCVBUF, [2048], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1) = 0 +0 < S 0:0(0) win 32792 +0 > S. 0:0(0) ack 1 +.1 < . 1:1(0) ack 1 win 1024 +0 accept(3, ..., ...) = 4 +0 %{ assert tcpi_snd_wscale == 0, tcpi_snd_wscale }% On Mon, Nov 9, 2020 at 12:02 PM Eric Dumazet wrote: > > On Mon, Nov 9, 2020 at 11:12 AM Mao Wenan wrote: > > > > > > > > 在 2020/11/9 下午5:56, Eric Dumazet 写道: > > > 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 ? > > 1)in tcp_v4_send_synack, if SO_RCVBUF is set and > > tcp_full_space(sk)=65535, pass req->rsk_window_clamp=65535 to > > tcp_select_initial_window, rcv_wscale will be zero, and send to client, > > the client consider wscale is 0; > > 2)when ack is back from client, if there is no this patch, > > req->rsk_window_clamp is 0, and pass to tcp_select_initial_window, > > wscale will be 7, this new rcv_wscale is no way to advertise to client. > > 3)if server send rcv_wind to client with window=63, it consider the real > > window is 63*2^7=8064, but client consider the server window is only > > 63*2^0=63, it can't send big packet to server, and the send-q of client > > is full. > > > > I see, please change your patches so that tcp_full_space() is used _once_ > > listener sk_rcvbuf can change under us. > > I really have no idea how window can be set to 63, so please send us > the packetdrill test once you have it.