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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 9055CC43460 for ; Mon, 10 May 2021 14:10:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 57C1561369 for ; Mon, 10 May 2021 14:10:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232677AbhEJOKv (ORCPT ); Mon, 10 May 2021 10:10:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57810 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244839AbhEJOFc (ORCPT ); Mon, 10 May 2021 10:05:32 -0400 Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 50955C06138F for ; Mon, 10 May 2021 06:47:08 -0700 (PDT) Received: by mail-ej1-x62e.google.com with SMTP id t4so24687902ejo.0 for ; Mon, 10 May 2021 06:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y090JTi5u7L+I2zANuVu8piJZcdJ8sLCVab3Loo8HmE=; b=Il76HL0QGBMxpyekRa88oVy+JUeZ43TQn0NZ2TMfuRFHZHX6ILVZUphgUPet3WV+yZ WupKE1kDUh8uWBEuf6Y6pcvdniqtR6uAMrLClBAxb9tR5OjAzjPL60OZLK36rw6mxctB nkVT17PqtqHU30rfWNAGs/xGf7NXjpMqa/VzTtoBpLlwYCVlBbO1Uo9ltJbisxGIlbQq tyfv5cLNSYZHt9x0a1Ro1/r8P4q/EskdDqQko+YNhiuQIo7w/U2+g/NQMHVqDL5ZWIR5 Y6KjXPMz4yQ4HNrJbc83UbhnQxGVpx+lP47VVD1dQHq9Ou737laTgsOW4Di5lMpmx/bk kqXg== 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=Y090JTi5u7L+I2zANuVu8piJZcdJ8sLCVab3Loo8HmE=; b=Re2ifcIchW9RWWqrmoFwn8ZqXn4+brU1WG/+jwnQWcndBPtmVvj0K9EiUB02l1qpUp 04flvxGBs+qhcueRt23HASlVe5LjZnvR648EkhQu0eInl7ncyjYt2vlaDvT1Yql4FmZz SzMhMaPxzuHQX+YgzPK7WCBPKBvxrv0SQdcXayajAG90jpJIP8opxutAuotvCPPb1DqH IrneoZFHDqPF8xcfQD+exglFocbDJ3z0ZoPEY9CstluWr83REp/5lgsQEc1Ebh6JN4ZS idkqDBxgyGGf6Sk1uviYQiZOpCmRTnwSFlR1GlKsPuVqJpobPvVheK8fy7X5m4u6rpvH GdZA== X-Gm-Message-State: AOAM531xbjXxRZahmPIUXNNB5oAyVzm+9k5OBWp39IrvURreAMD9qx66 nA69ZV4nFqZ6tlqlfyQ9ug4iGhid1x+Ung== X-Google-Smtp-Source: ABdhPJxBIF+UHe98NRT12Y+84P1c+c5lrBHzGpuW0Fpuly6W7WV7EundCrpeXblDIfJZ4HA8vo9clQ== X-Received: by 2002:a17:906:a295:: with SMTP id i21mr25426896ejz.160.1620654426318; Mon, 10 May 2021 06:47:06 -0700 (PDT) Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com. [209.85.221.47]) by smtp.gmail.com with ESMTPSA id aj8sm9169597ejc.64.2021.05.10.06.47.04 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 May 2021 06:47:04 -0700 (PDT) Received: by mail-wr1-f47.google.com with SMTP id l13so16677546wru.11 for ; Mon, 10 May 2021 06:47:04 -0700 (PDT) X-Received: by 2002:adf:e750:: with SMTP id c16mr31309348wrn.50.1620654423753; Mon, 10 May 2021 06:47:03 -0700 (PDT) MIME-Version: 1.0 References: <1619690903-1138-1-git-send-email-dseok.yi@samsung.com> <8c2ea41a-3fc5-d560-16e5-bf706949d857@iogearbox.net> <02bf01d74211$0ff4aed0$2fde0c70$@samsung.com> <02c801d7421f$65287a90$2f796fb0$@samsung.com> <001801d742db$68ab8060$3a028120$@samsung.com> <436dbc62-451b-9b29-178d-9da28f47ef24@huawei.com> <007001d7431a$96281960$c2784c20$@samsung.com> <00c901d74543$57fa3620$07eea260$@samsung.com> In-Reply-To: From: Willem de Bruijn Date: Mon, 10 May 2021 09:46:25 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH bpf] bpf: check for data_len before upgrading mss when 6 to 4 To: Willem de Bruijn Cc: Dongseok Yi , Yunsheng Lin , Daniel Borkmann , bpf , Alexei Starovoitov , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , "David S. Miller" , Jakub Kicinski , Network Development , linux-kernel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 10, 2021 at 9:19 AM Willem de Bruijn wrote: > > > > That generates TCP packets with different MSS within the same stream. > > > > > > My suggestion remains to just not change MSS at all. But this has to > > > be a new flag to avoid changing established behavior. > > > > I don't understand why the mss size should be kept in GSO step. Will > > there be any issue with different mss? > > This issue has come up before and that has been the feedback from > TCP experts at one point. > > > In general, upgrading mss make sense when 6 to 4. The new flag would be > > set by user to not change mss. What happened if user does not set the > > flag? I still think we should fix the issue with a general approach. Or > > can we remove the skb_increase_gso_size line? > > Admins that insert such BPF packets should be aware of these issues. > And likely be using clamping. This is a known issue. > > We arrived that the flag approach in bpf_skb_net_shrink. Extending > that to bpf_skb_change_proto would be consistent. As for more generic approach: does downgrading to non-TSO by clearing gso_size work for this edge case?