Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp31103rwb; Wed, 21 Sep 2022 16:56:17 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7Wsa0XoI3BRfqYUbLrWhST+8ww8t0RYdAYgIgwlqja+CNyWPGjazvssfpR0qnqPrOUjbdI X-Received: by 2002:a65:68c8:0:b0:438:744d:b340 with SMTP id k8-20020a6568c8000000b00438744db340mr623246pgt.142.1663804577008; Wed, 21 Sep 2022 16:56:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663804577; cv=none; d=google.com; s=arc-20160816; b=s2BctzzPFJf5T9kJpoIPOJreBmBGJYyNxNPEHQnGScAt0PXd2hicmZWSJkzo/NQ5oG OPjlK5WVGRWwsEdsO7vDtR0mG9wyz6snNAkKzUkIBg1XusN6JquK/3cEByFvMqVxaSGC gtxwtbzQcQ7Lx8heXaBXqghhHC9fJAtAze5nc4lnQUBnT08xLU0Os0yqZB0oU15Y0EnN WSMmvXj4wrkaZixAOoqQvArOO6r5jqSEZ50roXQTRLQu1GxakhtnCCUN2GmocBub/Bkl JtsQoE6IN4Z1MvPSb9A9W2Suhg6qBlzHPe0mVmVkyR7gRrr6XmH2SKqtBx98txbVNE7q 30CA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=wcBwRfOcQ0aBAEAgR2fCpIMAURfzSlApHm2GvjuJp+I=; b=kljo1OdMvtcY9lOR0WTTA8449IW3oJjgRyrwsmVkZkDdwDMf9ZqsHYEPo43MZZN00z uiW9KnjqM7nE3rqMmFmdR87UxYNzN2RmTiPQ9rnMfyPD/+3xyqIfGdYms3kb9Oi9BK1D 2rvp99wrS5ZLfQoUe/TsvS6a37Abc1pnP1/e4sppCqPkvY0H7VtlgPqRNBVryvggCauJ n0KczwyMffmzuJfx5cyN3iRN18YG3LIx6fzmCh/mF9QFIPn/2Bo5KkWcNiSIp/sZHaS3 oF2DmYULeLLtMrGOfh4pfYWzmcqQYFXN/PKZzrPIvCyVWW+qpgT8DlW9pycshuayfeqt pw8Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=QiG5+P5U; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a11-20020a170902eccb00b001769fce8c2fsi4662143plh.485.2022.09.21.16.56.05; Wed, 21 Sep 2022 16:56:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=QiG5+P5U; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229803AbiIUXdf (ORCPT + 99 others); Wed, 21 Sep 2022 19:33:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45468 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229543AbiIUXdd (ORCPT ); Wed, 21 Sep 2022 19:33:33 -0400 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C1529A5980; Wed, 21 Sep 2022 16:33:31 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id y17so17236519ejo.6; Wed, 21 Sep 2022 16:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=wcBwRfOcQ0aBAEAgR2fCpIMAURfzSlApHm2GvjuJp+I=; b=QiG5+P5UyRh+xcWeHuWwWXVwsmEl3xKYP0TkikiZvurzaYzDbNmEEVLI5FmB0MIfgt pag5jJepynQEHN/+t3aUVs8GmXMtDDoUIyRovTtXxTof7TqA13a95FH2Lg7xUDuxM/2A jvbbKgQ5dTvOGhDsMsJgIwtvNCpiRKLheP9tYl3q/i3lXbHqNiXNm7IWceL+AlyE3sCt dcnPBkaIMA8I6M0gJN8+1/2LoNCO9GpbQE+tptun9J+iwWlrcUZWjIH+s9iRKRnh/3l3 JsjLxEIOk5lvQQ+uWgbaDiv6ha8angSfIc8MqQZ1gVA1YmsZN/GJ771kyqelJPqwDDZV adRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=wcBwRfOcQ0aBAEAgR2fCpIMAURfzSlApHm2GvjuJp+I=; b=pMypRiL1wX1XzOFNbID3R1jti4nxHDHmfDKQso3d+pxi3f1O9a3XpGSxbckyu8lLg6 R4K1P8iYQDX5I2guiVuZvrBcHZk0jPv2KfL/KV+tH3Qz2x3txiNamponG7yn/GgbHG2Y kgvvxcrH/qNMCqf0GQNTC0NkjUsCigRfpg5tKMmPwvVogyv1NIpJXPxRWShotBHqKI+j 4pF6zwjasJbvZW6PZNur7gMNeccHx8VwdYHSj4QjwdmsCw6cqu8BhBpNiTy/TZW4n2Fz u+DgTba/bib5MgkHnaH6LHmH06k8JHo+/RfPTzhe9kOQWCg612ou0Omdpgh57/Yu+kdP WxSA== X-Gm-Message-State: ACrzQf2ajeVNFAgq2uR1fAEf4pXqSGz9/lW3JiBgymKFLgZ2QBKs0YQ4 nxWHfK5j7/6xfQ8u4J4VUVys6LSOlggj9ydHLuk= X-Received: by 2002:a17:906:99c5:b0:73d:70c5:1a4f with SMTP id s5-20020a17090699c500b0073d70c51a4fmr529596ejn.302.1663803210145; Wed, 21 Sep 2022 16:33:30 -0700 (PDT) MIME-Version: 1.0 References: <20220920000100.477320-1-void@manifault.com> <20220920000100.477320-3-void@manifault.com> In-Reply-To: <20220920000100.477320-3-void@manifault.com> From: Andrii Nakryiko Date: Wed, 21 Sep 2022 16:33:18 -0700 Message-ID: Subject: Re: [PATCH v6 2/4] bpf: Add bpf_user_ringbuf_drain() helper To: David Vernet Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev, kernel-team@fb.com, song@kernel.org, yhs@fb.com, john.fastabend@gmail.com, kpsingh@kernel.org, sdf@google.com, haoluo@google.com, jolsa@kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org, tj@kernel.org, brho@google.com, joshdon@google.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 19, 2022 at 5:01 PM David Vernet wrote: > > In a prior change, we added a new BPF_MAP_TYPE_USER_RINGBUF map type which > will allow user-space applications to publish messages to a ring buffer > that is consumed by a BPF program in kernel-space. In order for this > map-type to be useful, it will require a BPF helper function that BPF > programs can invoke to drain samples from the ring buffer, and invoke > callbacks on those samples. This change adds that capability via a new BPF > helper function: > > bpf_user_ringbuf_drain(struct bpf_map *map, void *callback_fn, void *ctx, > u64 flags) > > BPF programs may invoke this function to run callback_fn() on a series of > samples in the ring buffer. callback_fn() has the following signature: > > long callback_fn(struct bpf_dynptr *dynptr, void *context); > > Samples are provided to the callback in the form of struct bpf_dynptr *'s, > which the program can read using BPF helper functions for querying > struct bpf_dynptr's. > > In order to support bpf_ringbuf_drain(), a new PTR_TO_DYNPTR register > type is added to the verifier to reflect a dynptr that was allocated by > a helper function and passed to a BPF program. Unlike PTR_TO_STACK > dynptrs which are allocated on the stack by a BPF program, PTR_TO_DYNPTR > dynptrs need not use reference tracking, as the BPF helper is trusted to > properly free the dynptr before returning. The verifier currently only > supports PTR_TO_DYNPTR registers that are also DYNPTR_TYPE_LOCAL. > > Note that while the corresponding user-space libbpf logic will be added > in a subsequent patch, this patch does contain an implementation of the > .map_poll() callback for BPF_MAP_TYPE_USER_RINGBUF maps. This > .map_poll() callback guarantees that an epoll-waiting user-space > producer will receive at least one event notification whenever at least > one sample is drained in an invocation of bpf_user_ringbuf_drain(), > provided that the function is not invoked with the BPF_RB_NO_WAKEUP > flag. If the BPF_RB_FORCE_WAKEUP flag is provided, a wakeup > notification is sent even if no sample was drained. > > Signed-off-by: David Vernet > --- > include/linux/bpf.h | 11 +- > include/uapi/linux/bpf.h | 38 +++++++ > kernel/bpf/helpers.c | 2 + > kernel/bpf/ringbuf.c | 181 ++++++++++++++++++++++++++++++++- > kernel/bpf/verifier.c | 61 ++++++++++- > tools/include/uapi/linux/bpf.h | 38 +++++++ > 6 files changed, 320 insertions(+), 11 deletions(-) [...] > #define __BPF_FUNC_MAPPER(FN) \ > FN(unspec), \ > @@ -5599,6 +5636,7 @@ union bpf_attr { > FN(tcp_raw_check_syncookie_ipv4), \ > FN(tcp_raw_check_syncookie_ipv6), \ > FN(ktime_get_tai_ns), \ > + FN(user_ringbuf_drain), \ > /* */ > > /* integer value in 'imm' field of BPF_CALL instruction selects which helper > diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c > index 41aeaf3862ec..66217b1857ca 100644 > --- a/kernel/bpf/helpers.c > +++ b/kernel/bpf/helpers.c > @@ -1627,6 +1627,8 @@ bpf_base_func_proto(enum bpf_func_id func_id) > return &bpf_dynptr_write_proto; > case BPF_FUNC_dynptr_data: > return &bpf_dynptr_data_proto; > + case BPF_FUNC_user_ringbuf_drain: > + return &bpf_user_ringbuf_drain_proto; In light of [0], where we now allow dynptr only with CAP_BPF, I've moved this lower behind CAP_BPF check while applying. Thanks! [0] https://patchwork.kernel.org/project/netdevbpf/patch/20220921143550.30247-1-memxor@gmail.com/ > default: > break; > } [...]