Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp3225427pxb; Mon, 9 Nov 2020 06:03:35 -0800 (PST) X-Google-Smtp-Source: ABdhPJwCnnFsV2y5eU60u2JLFyzWYofck8p17MzAedV7lryrjc+bndbSyLhSj9oMaaECjnzfrs2O X-Received: by 2002:a17:906:604e:: with SMTP id p14mr15931109ejj.515.1604930614773; Mon, 09 Nov 2020 06:03:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604930614; cv=none; d=google.com; s=arc-20160816; b=hJO7ZTUa0T8j3uoXf008pL5nBHxZjprpUDKg8slCBxn7uDXePB5LEJyB1kd2Ys5fFF OwGLC3mPAAi0C2Pj4qJBz0RYDsYdHU0Y2GBwlxzboQGdpRmBAeckQeUKIwaf+5bfIskr Z6c1rRKki/V3gFFgdKvRnqMHseEdl7XPf9yFxNno3C149xvZZM4oQ4OYi6y2IcQKBW5i begSbI0sLKEJibxbk0ldVgepYvt6LFnAc75ZnLcFrEiMdu2TLtfr/yXA4LQEFTnbaTqD kQ7ct8oKD0rTvCpnV0bnY++bwvp/PxH+/z7Bi7vVtSaAQmy47EI2aE5zjSchcKwTr1kH ZR8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=R/y3h2V8KUh2HjjXpKhtsmK1j3JU5Ik5x1QmKjAc+dw=; b=YMlVaJdwQqkvufKZLiPGorRUJ71exknOrftxJU3a68ngnQAPYBISXbILWqVXh9BHrH 1abSHH4lXTv402Cs3SKRKWFZI8+kT0HonqXCw8Z510gB4j3NqHmZwls2P6Eexw8SNGXE Z2IgJOMSGL3R+3sGicHw/BkrZw1wjpLzhEy4sWLRo1lWZCKxQ4mRcNzC/1l+SWsWcfBL F2Fu4XXHzIOMoXKUWQtfRzhylHLlIEwXQO43cvrf3htMFJBJ2Vn5+x+f2LJJpdu+wDE7 sy2muSo8iAXmyket0ecP5ZdnOjnNkXptmSmj4kwFB9tC79NDCKQ7s0anLrZRPqDHYs8h SDtw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=sCHfxt1T; 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 f13si7059296edx.450.2020.11.09.06.03.08; Mon, 09 Nov 2020 06:03:34 -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=sCHfxt1T; 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 S1731342AbgKIOBk (ORCPT + 99 others); Mon, 9 Nov 2020 09:01:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58752 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730141AbgKIOBk (ORCPT ); Mon, 9 Nov 2020 09:01:40 -0500 Received: from mail-il1-x141.google.com (mail-il1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3F2AAC0613D4 for ; Mon, 9 Nov 2020 06:01:40 -0800 (PST) Received: by mail-il1-x141.google.com with SMTP id y9so1253377ilb.0 for ; Mon, 09 Nov 2020 06:01:40 -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=R/y3h2V8KUh2HjjXpKhtsmK1j3JU5Ik5x1QmKjAc+dw=; b=sCHfxt1Tg+i5nd302fB2fuH/skV5z9YHP9zYsSGc+aivet4eZV9LHp1n4S5VD2JxlQ vlxHzm2jS2InJ+TtETBPTBs1m/UII6vtfBDqJB3/vIzvBiK5JouLCXz85fRCfIkVE3AP TmugfLHQze9u3h5/dP46mop+7w+c8kW01+ra0FgUSXDlvZZUKm6OA+COJ9N/z20roiCm dkvM1tsT/0jbVgsYqUzvQEtMsoyjgcStAwZGd/ekeDI7v63A2IO5x0xXKsaI7Y/Qzq5F vqQmcg7CRlZgrQu0M4KqGWEduol6rT0cjgG8W+/wAIwrczKmwNMqkuuBmNNloI0buZ7Y uKSA== 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=R/y3h2V8KUh2HjjXpKhtsmK1j3JU5Ik5x1QmKjAc+dw=; b=fA+eXG93q2S5I3B+eacovBAYDzFst66e12sii+seYBErSkKORcdWxT6RlF+d2wGDxi cWy6NUZO2s7/aQZu/+1Y5xHSww4ZN5xy7BNoPE+Hr75KholqmIg0NFAokW62docX17cX YaREGoiQIzsa2FmXN4bgD0/T520EwR4OoWkVz+RKxwaxsu011DlSjXwDqxOxP+tvFmEc aVlu6DUXbgdyivjB9+YYa5NPoxCn97BdiIyO8tLeZ+YX19qnj9ovA6OL33Qpwq2mKwYe ftZavDomwnIt6i4Uu3pqYAmQk4YiiXRt+8Uzg7V9n0Dm3oa9lidr1jfDFCveUm8VsDri bVJA== X-Gm-Message-State: AOAM532rq76pvShznGXbWcDaspZWpk/NY3OXM8ylaYKmS/Bi/Stln6Jg YwGoqEq+zxH1xR5etg2/URcjsVdVM7W+QARQc+hnyw== X-Received: by 2002:a92:6f11:: with SMTP id k17mr10207429ilc.69.1604930499398; Mon, 09 Nov 2020 06:01:39 -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 15:01:27 +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 On Mon, Nov 9, 2020 at 12:41 PM Eric Dumazet wrote: > > 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 }% > Also, please add to your next submission an appropriate Fixes: tag : Fixes: e88c64f0a425 ("tcp: allow effective reduction of TCP's rcv-buffer via setsockopt") > On Mon, Nov 9, 2020 at 12:02 PM Eric Dumazet wrote: > > > > On Mon, Nov 9, 2020 at 11:12 AM Mao Wenan = wrote: > > > > > > > > > > > > =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 the= re > > > > 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 clien= t, > > > 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 clien= t. > > > 3)if server send rcv_wind to client with window=3D63, it consider the= real > > > window is 63*2^7=3D8064, but client consider the server window is onl= y > > > 63*2^0=3D63, it can't send big packet to server, and the send-q of cl= ient > > > is full. > > > > > > > I see, please change your patches so that tcp_full_space() is used _onc= e_ > > > > 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.