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=-7.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, 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 5D97EC282CB for ; Tue, 5 Feb 2019 20:20:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2FADF2073D for ; Tue, 5 Feb 2019 20:20:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="u5a0rIxh" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729790AbfBEUUU (ORCPT ); Tue, 5 Feb 2019 15:20:20 -0500 Received: from mail-ed1-f68.google.com ([209.85.208.68]:36876 "EHLO mail-ed1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727280AbfBEUUT (ORCPT ); Tue, 5 Feb 2019 15:20:19 -0500 Received: by mail-ed1-f68.google.com with SMTP id h15so4018945edb.4 for ; Tue, 05 Feb 2019 12:20:18 -0800 (PST) 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=xRtAlJ33oxzliGu5VzJc0Odu2212sHTDrYgbA0uqBME=; b=u5a0rIxhbEWeRFnjr3LRMSKsSUeTXvTCnxUrUupkTk3HJVIRAlplGoqh84TU2u63Vz i6QcqdD1ncPTqtSd6alWxwzwigkoCkvSzZUVLPblYJIZg+b+tvsFdEPDAbbhFUlk2Atn VkpMoSH6t8hRbwVBu7y0aUiTOlTl/usASdfF5mkb3ef9sMnD2hDGfP4arBjvBFMuicd1 a/WJlbdrEHm7ZpHMoXHiitSMim7oeQrB9cZe9CpE/mLzgexNtPvmf7QTg6D22DlI3hWx VXm0jkzyuUqrKh1L8R8+6mQLyItrRZ7GlsvWkxWOY3CZIkP5nUSwvJBpDhCKk/VJbGth wQoQ== 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=xRtAlJ33oxzliGu5VzJc0Odu2212sHTDrYgbA0uqBME=; b=WSbnyIjKoVUYKZEsL3Ej632rIqvSykWSjKulOCX8kVJWPF3o3/3bd5AFRNp6MgXMQ1 5IHovlTTIgcw4CnUF106aMLd0GbSYd/7a1uXbAVsH1FZ3NU/D6Qt/y7LdTJ8V7vzTibT 5n6ko1AdHqfDRcI5fyOpISqncvOJBrcbA1WmYKGGJA+LeqNSvtKPq9T7w5BLlcdLkT2y +s3x9smUp3/F69Gmtah7JzER1RKokI/d1vLonPEQy/xQpZwnVUbpM/djxHlJRmdq72BE o8iNPTRjvY9H7vEbZa2D26JcexN3KTtypQREZSPwtK1ZkdJnY4p7yww4fSWj82JkMJuq 53wQ== X-Gm-Message-State: AHQUAua8uWEybVmNKvaimjyiMFycK/zjeRR9yuOvc2jILU9ONpYuo691 aF88fSZgxZBflM/Tqtdw5JiPe4YReRZWkGVIIHc= X-Google-Smtp-Source: AHgI3IaIFHFheVrzBZQnCx2ey2A1q2WppIrpGv+MA/w8ScFZzHv9Ed395QIQoLiPIL+jq3/oWogGlt3yPwhOq6MYXzM= X-Received: by 2002:a50:983a:: with SMTP id g55mr5418309edb.143.1549398017600; Tue, 05 Feb 2019 12:20:17 -0800 (PST) MIME-Version: 1.0 References: <20190205173629.160717-1-sdf@google.com> <20190205173629.160717-5-sdf@google.com> In-Reply-To: <20190205173629.160717-5-sdf@google.com> From: Willem de Bruijn Date: Tue, 5 Feb 2019 15:19:41 -0500 Message-ID: Subject: Re: [RFC bpf-next 4/7] net: flow_dissector: handle no-skb use case To: Stanislav Fomichev Cc: Network Development , David Miller , Alexei Starovoitov , Daniel Borkmann , simon.horman@netronome.com, Willem de Bruijn 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 Tue, Feb 5, 2019 at 12:57 PM Stanislav Fomichev wrote: > > When flow_dissector is called without skb (with only data and hlen), > construct on-stack skb (which has a linear chunk of data passed > to the flow dissector). This should let us handle eth_get_headlen > case where only data is provided and we don't want to (yet) allocate > an skb. > > Since this on-stack skb doesn't allocate its own data, we can't > add shinfo and need to be careful to avoid any code paths that use > it. Flow dissector BPF programs can only call bpf_skb_load_bytes helper, > which doesn't touch shinfo in our case (skb->len is the length of the > linear header so it exits early). > > Signed-off-by: Stanislav Fomichev > --- > include/linux/skbuff.h | 5 +++ > net/core/flow_dissector.c | 95 +++++++++++++++++++++++++++++---------- > 2 files changed, 76 insertions(+), 24 deletions(-) > > diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h > index aa9a9983de80..5f1c085cb34c 100644 > --- a/include/linux/skbuff.h > +++ b/include/linux/skbuff.h > @@ -1227,6 +1227,11 @@ bool __skb_flow_bpf_dissect(struct bpf_prog *prog, > const struct sk_buff *skb, > struct flow_dissector *flow_dissector, > struct bpf_flow_keys *flow_keys); > +bool __flow_bpf_dissect(struct bpf_prog *prog, > + void *data, __be16 proto, > + int nhoff, int hlen, > + struct flow_dissector *flow_dissector, > + struct bpf_flow_keys *flow_keys); nit: please use more descriptive name. Perhaps bpf_flow_dissect_raw and rename __skb_flow_bpf_dissect to bpf_flow_dissect_skb. > +bool __flow_bpf_dissect(struct bpf_prog *prog, > + void *data, __be16 proto, > + int nhoff, int hlen, > + struct flow_dissector *flow_dissector, > + struct bpf_flow_keys *flow_keys) > +{ > + struct bpf_skb_data_end *cb; > + struct sk_buff skb; > + u32 result; > + > + __init_skb(&skb, data, hlen); > + skb_put(&skb, hlen); > + skb.protocol = proto; > + > + init_flow_keys(flow_keys, &skb, nhoff); > + > + cb = (struct bpf_skb_data_end *)skb.cb; > + cb->data_meta = skb.data; > + cb->data_end = skb.data + skb_headlen(&skb); > + > + result = BPF_PROG_RUN(prog, &skb); > + > + clamp_flow_keys(flow_keys, hlen); > > return result == BPF_OK; > } Can__flow_bpf_dissect just construct an skb and then call __skb_flow_bpf_dissect? It will unnecessarily save and restore the control block, but that is a relatively small cost (compared to, say, zeroing the entire skb).