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.6 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 12809C10F14 for ; Thu, 11 Apr 2019 22:26:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D590521850 for ; Thu, 11 Apr 2019 22:25:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="PHx0n3YZ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726897AbfDKWZ6 (ORCPT ); Thu, 11 Apr 2019 18:25:58 -0400 Received: from mail-lj1-f194.google.com ([209.85.208.194]:42773 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726728AbfDKWZ6 (ORCPT ); Thu, 11 Apr 2019 18:25:58 -0400 Received: by mail-lj1-f194.google.com with SMTP id v22so7005489lje.9 for ; Thu, 11 Apr 2019 15:25:57 -0700 (PDT) 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; bh=mLPKjn8BQfaK59DjTSl/PYkQ6vhd1km9Kry4eExEeuk=; b=PHx0n3YZLKIf0SEemfRmQE5t1xJSYsXhRHLaFy44lwFlOMshML7TIRTCOVKNSZJo7r vaPEbL9w2PWMgh/DlB6/iqzPjI/mIVyFIZu4dXlLQDffvgcuYi95sACRapvuZv7it7y+ Htu+lBpUx5LLFwjedIB5S6mBn49l0GVhBacR8bKFqS8Hk8cCQ5EsiM9BLXQKe1VTyvmP hzK/1pDKDplQ34567gUIDbSgY/oofo7zSvlj9bNvUdDhLybj5vbkY+mLqoRZeWsgzeFL bYjrACxWC2T+HxNCLfKWA9jTS9BHkTau+BEShamX+MELGUD95xub2pRJwzmfV9FxEQjF JbKg== 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=mLPKjn8BQfaK59DjTSl/PYkQ6vhd1km9Kry4eExEeuk=; b=G7XeRquetrGuVM4ovb8IltRnkisFraAjw61C7RBsSn6I8qCv3mK2pyHxrEZV0F+pay pzwiBN4gfw9c+kJ+AFKi7A1J8wqRTB3JS4oNq4ynnG+DDAGXSnTVYALqKZODL+N+v486 P6UcwfukeEhbc7dw2hmzb2JUuhwBB9TIQ83DffJMexx6MmJPGr05elQ7hhAYm4RYAkjK eDb77UGk4EIfJXs/mdcvH3lQzzvfIDnUNYgQCRwGW8BrSwlzd5cnyWFE1xg0OwQM/c/k 2eyL6Q8kxm+vH8kSwDY7O9339+qyKOaXxrPDuVz0Ms46qdUxa0wLulPklzsZRQT1jRPf ZiaQ== X-Gm-Message-State: APjAAAXO62SLt8eU0sPF5u/8ty5WBbnEsZL+yT0msFxx+C3A80xT8aaZ DDISj7z7Y6EGwPAG7DjGDhfWgEOFWjt6zig2ywypSA== X-Google-Smtp-Source: APXvYqxxxWEcfMfjjf07IdXCuDa8xoyFsfgUOGfZPiyx0uhe27URlzMRQ8cKFXyY9pHXXJuTlwON3tGXPKJTzB75Jc0= X-Received: by 2002:a2e:b058:: with SMTP id d24mr396685ljl.42.1555021555961; Thu, 11 Apr 2019 15:25:55 -0700 (PDT) MIME-Version: 1.0 References: <20190409184911.97485-1-sdf@google.com> <3e26d75a-da10-9ae2-12f8-893f334fa1e9@iogearbox.net> In-Reply-To: <3e26d75a-da10-9ae2-12f8-893f334fa1e9@iogearbox.net> From: Stanislav Fomichev Date: Thu, 11 Apr 2019 15:25:44 -0700 Message-ID: Subject: Re: [PATCH bpf-next v4 1/3] bpf: support input __sk_buff context in BPF_PROG_TEST_RUN To: Daniel Borkmann Cc: Netdev , bpf@vger.kernel.org, David Miller , Alexei Starovoitov , Martin Lau Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Apr 11, 2019 at 3:23 PM Daniel Borkmann wrote: > > Hey Stanislav, > > On 04/09/2019 08:49 PM, Stanislav Fomichev wrote: > > Add new set of arguments to bpf_attr for BPF_PROG_TEST_RUN: > > * ctx_in/ctx_size_in - input context > > * ctx_out/ctx_size_out - output context > > > > The intended use case is to pass some meta data to the test runs that > > operate on skb (this has being brought up on recent LPC). > > > > For programs that use bpf_prog_test_run_skb, support __sk_buff input and > > output. Initially, from input __sk_buff, copy _only_ cb and priority into > > skb, all other non-zero fields are prohibited (with EINVAL). > > If the user has set ctx_out/ctx_size_out, copy the potentially modified > > __sk_buff back to the userspace. > > > > We require all fields of input __sk_buff except the ones we explicitly > > support to be set to zero. The expectation is that in the future we might > > add support for more fields and we want to fail explicitly if the user > > runs the program on the kernel where we don't yet support them. > > > > The API is intentionally vague (i.e. we don't explicitly add __sk_buff > > to bpf_attr, but ctx_in) to potentially let other test_run types use > > this interface in the future (this can be xdp_md for xdp types for > > example). > > > > v4: > > * don't copy more than allowed in bpf_ctx_init [Martin] > > > > v3: > > * handle case where ctx_in is NULL, but ctx_out is not [Martin] > > * convert size==0 checks to ptr==NULL checks and add some extra ptr > > checks [Martin] > > > > v2: > > * Addressed comments from Martin Lau > > > > Cc: Martin Lau > > Signed-off-by: Stanislav Fomichev > > This still has a bug in that we need to reject !bpf_prog_test_run_skb() cases, > since they are not handled by your set. So for e.g. XDP, flow dissector progs, > we need to error out if ctx is set such that it can be safely extended in future. > Please follow up. Good point, sure, will follow up on that! > Thanks, > Daniel