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=-1.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_PASS autolearn=ham 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 708BAC43381 for ; Sat, 2 Mar 2019 02:27:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2D63220815 for ; Sat, 2 Mar 2019 02:27:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="PgV9Xwpp" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726968AbfCBC1X (ORCPT ); Fri, 1 Mar 2019 21:27:23 -0500 Received: from mail-pl1-f194.google.com ([209.85.214.194]:43213 "EHLO mail-pl1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726412AbfCBC1X (ORCPT ); Fri, 1 Mar 2019 21:27:23 -0500 Received: by mail-pl1-f194.google.com with SMTP id m10so12322740plt.10 for ; Fri, 01 Mar 2019 18:27:22 -0800 (PST) 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=YkX9xNnoyH+LhKlnmDYMYjf+4l45K0ezgFMhoCyK5fw=; b=PgV9Xwpp3kNfgKOSuSuZpEcgEYVEQVGPuy3O8YUYaTHJq0mZLBLCspTh9Q/OLflZ5K LWX/18Cbn+H1bwq9zpFK08YI9snd1Lu8nT2iWp9hqqqNhBKhFmpeLeh2pNIMEm5FqrB3 pLLepOtqxCphVRSndUUdFeoZnsJQ85v8bCuPfyOO9ZlsjEnwXbU5f1WFiqMx3j5+riYo NKWxD49KuW1y4RzDWRTclScUDSI7vE1it5o81O70Dsp7iEeuK5Ohne+J2wiA/8n0i6ND nWZR2OA6gzNRPPegubMlBvnNcwIyWNKi7Ce8zbA5ntBvY9WwaaoxFg3G2YArBA+mTWIM t8iQ== 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=YkX9xNnoyH+LhKlnmDYMYjf+4l45K0ezgFMhoCyK5fw=; b=gbExcxeRjt5DQLy3fURpK4KlzlNOkSsAHSF+vJ5HNvXH+XgxX707Tgrw3elmA9HFt3 GNrySPRVMvyhKFNA6DRhK6kk4LC1FD47blNe2pvA3RErWKM/Yc24PtYx1Y/4ahJ7F9O6 /1iDevqizDEluK2qk6w9b5wJWYs4/hH+NZzOZBbTIv3n+/HXeVD6yfxOQ5lJ1PGXxVaH qZG+hwLYhQIHeo+ek4eLasSIwWxG4cGazEECu4fq9F1nJb3QfUzM8J/yX0w1gCDGz5eS Lbpl59iSPxpdBNw9kMhvyB0UmsgKNOUQgSrl1RlaS2lhLdBlxJLuGZ9q9/OoDIpB97A7 EpSQ== X-Gm-Message-State: APjAAAVPMqHZ2QNLAAe3xEAvHPX7qRI30oMus0e+1YU7y0lCpv17CzJD ekeyNdNguJMQj37KfUhg6gE= X-Google-Smtp-Source: APXvYqztvx/Sl+q239jk2xsRb1Vf8zOkhj/sELR80lkiQKnWtMeEprZyQOomsQhevOHVQ2eNqVnUaQ== X-Received: by 2002:a17:902:9a4a:: with SMTP id x10mr8476038plv.93.1551493642229; Fri, 01 Mar 2019 18:27:22 -0800 (PST) Received: from ?IPv6:2601:282:800:fd80:505f:7d9a:3851:b3e3? ([2601:282:800:fd80:505f:7d9a:3851:b3e3]) by smtp.googlemail.com with ESMTPSA id g71sm51273031pfg.157.2019.03.01.18.27.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Mar 2019 18:27:21 -0800 (PST) Subject: Re: [PATCH bpf-next] bpf: fix memory leak in bpf_lwt_xmit_reroute To: Peter Oskolkov Cc: Peter Oskolkov , Alexei Starovoitov , Daniel Borkmann , netdev , Willem de Bruijn References: <20190214060939.101851-1-posk@google.com> <733c9f8e-2262-dbff-6aa6-f960983812ab@gmail.com> <8f52efda-b502-2bfb-c881-8833bac461c2@gmail.com> From: David Ahern Message-ID: <04fdb303-ceee-07b5-be56-89b63dca28f0@gmail.com> Date: Fri, 1 Mar 2019 19:27:19 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 2/28/19 10:57 AM, Peter Oskolkov wrote: > David: I'm not sure how to test GSO (I assume we are talking about GSO > here) in > the selftest: the encapping code sets SKB_GSO_DODGY flag, and veth does > not support > dodginess: "tx-gso-robust: off [fixed]". > > If the "dodgy" flag is not set, then gso validation in dev.c passes, and > large GSO packets > happily go through; if the "dodgy" flag is set, "dodgy" GSO packets are > rejected, TCP does > segmentation, and non-GSO packets happily go through (with an mtu tweak > to the LWT tunnel). > > So I see three options: > - add a sysctl to _not_ set SKB_GSO_DODGY flag in lwt_bpf.c => > handle_gso_type(); > - change veth to accept "dodgy" GSO packets > - test the code "as is", meaning that GSO will be tried and disabled by > TCP stack > > Which approach would you prefer? > definitely not a sysctl. After that, I don't have a suggestion for GSO at the moment.