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=-2.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 76D0DC742A2 for ; Thu, 11 Jul 2019 18:29:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 355F8208E4 for ; Thu, 11 Jul 2019 18:29:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="tz8FeD49" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728721AbfGKS3F (ORCPT ); Thu, 11 Jul 2019 14:29:05 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:44402 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728689AbfGKS3F (ORCPT ); Thu, 11 Jul 2019 14:29:05 -0400 Received: by mail-wr1-f68.google.com with SMTP id p17so7314034wrf.11 for ; Thu, 11 Jul 2019 11:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=h/h6b8oGyNXq3Gke5g9TT3p/XLPsLUUIgpj6GKZbRJw=; b=tz8FeD497u5PEdlWyjGOsT+RNrYPtDZaSkMuLMaE3gkNLVhCwieBHEN21KwVfsMK9i 9BnrcDlehoiHUUP84n9+XP5lpSff+Ut5WUenIMDrhhGaoqeHBU4eIv6xgN9vqZqMS1sb JOF8Sk9wdM4piIdDYkqp3Ad7Gm/Cg+V1pWN+PeR5czdZzDCpXcDpt/j0R5Fh97RyZvkW /MpRBa6vsNKfsetOLhy7L/swAzB1+WdhE2AamZfdOVOUbBIK22Y7DkMq5zJQg71pDx/h eo41Y5X1RkScxtifYNGRNhRShhveAEswhxrQAt9ABnsU1yxH/xbdwJAaNHC0NbqNpltV 7Tjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=h/h6b8oGyNXq3Gke5g9TT3p/XLPsLUUIgpj6GKZbRJw=; b=pf8CpNylKXwKpUYcj3/FiMzaAIC4VAOulO5a2Yp83UYWozkcx731708OkbHXH39hA9 q5L2wAk8Y7GDazbfRBYY8ZR0Bu/wO3NqCSKGZ55zlxOuQYxwrwCgxiMLItOIRdq4LN3J xbXcn148biFU9eoGVm4rQK0Hf6/yurT6GLd2O8wIOodpixy7pI4zuGbNfRB06QC3sNDm 51OIgfzD8UAQQlbPautQfF96Mv/GaC+N6U7/Ohn9spcFeIyj88qmgdW2BMwqgxD4xwNb L/fOUYRI6UU0nX2FTRCuc5yhPWT9a9AlMXbgDSzOy6AzIrztEaql1BL18Y5bR528aEnw jI/g== X-Gm-Message-State: APjAAAUZTHmONDKN0Ul0kGtvlHwVHis6Q7fBi5R3Aqb8lMPy3rrdzPNf 1aVuvKWJb3valNLePpuXLjI= X-Google-Smtp-Source: APXvYqyzakva52IvKukBgwa4oNowHM7jENJvh4zUKN6gBmPYEgloy4Zojb1omYSgMHuTtu4vGfS2Gw== X-Received: by 2002:a5d:518f:: with SMTP id k15mr6302342wrv.321.1562869742837; Thu, 11 Jul 2019 11:29:02 -0700 (PDT) Received: from [192.168.8.147] (143.160.185.81.rev.sfr.net. [81.185.160.143]) by smtp.gmail.com with ESMTPSA id c12sm9614606wrd.21.2019.07.11.11.29.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jul 2019 11:29:01 -0700 (PDT) Subject: Re: [PATCH net 2/4] tcp: tcp_fragment() should apply sane memory limits To: "Prout, Andrew - LLSC - MITLL" , Eric Dumazet , Christoph Paasch Cc: "David S . Miller" , netdev , Greg Kroah-Hartman , Jonathan Looney , Neal Cardwell , Tyler Hicks , Yuchung Cheng , Bruce Curtis , Jonathan Lemon , Dustin Marquess References: <20190617170354.37770-1-edumazet@google.com> <20190617170354.37770-3-edumazet@google.com> <03cbcfdf-58a4-dbca-45b1-8b17f229fa1d@gmail.com> <63cd99ed3d0c440185ebec3ad12327fc@ll.mit.edu> <96791fd5-8d36-2e00-3fef-60b23bea05e5@gmail.com> From: Eric Dumazet Message-ID: Date: Thu, 11 Jul 2019 20:28:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 7/11/19 7:14 PM, Prout, Andrew - LLSC - MITLL wrote: > > In my opinion, if a small SO_SNDBUF below a certain value is no longer supported, then SOCK_MIN_SNDBUF should be adjusted to reflect this. The RCVBUF/SNDBUF sizes are supposed to be hints, no error is returned if they are not honored. The kernel should continue to function regardless of what userspace requests for their values. > It is supported to set whatever SO_SNDBUF value and get terrible performance. It always has been. The only difference is that we no longer allow an attacker to fool TCP stack and consume up to 2 GB per socket while SO_SNDBUF was set to 128 KB. The side effect is that in some cases, the workload can appear to have the signature of the attack. The solution is to increase your SO_SNDBUF, or even better let TCP stack autotune it. nobody forced you to set very small values for it.