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 13C70C2D0A3 for ; Mon, 9 Nov 2020 14:01:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AAFB420657 for ; Mon, 9 Nov 2020 14:01:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="sCHfxt1T" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729871AbgKIOBk (ORCPT ); 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-Google-Smtp-Source: ABdhPJxaKVOuDzlxhdWUNS2F1aDUsYr9TZS1F1EZaAf/eBNGDDQ34ZzmFykw1qVrgV1xaz+EFOmyT71gy0MuHe/FhxA= 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Date: Mon, 09 Nov 2020 14:01:27 +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 On Mon, Nov 9, 2020 at 12:41 PM Eric Dumazet wrote: > > 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 }% > 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: > > > > > > > > > > > > 在 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.